Canbus retransmissions error.

[SoftTransistor]

Hello,

I'm in the process of trying to reverse engineering a propriety canbus of some broadcast related equipment. My problem is that when I try to record the messages on the bus, I get so much retransmission that no message is transmitted anymore.

My setup:
- I have two nodes of the equipment to reverse engineer connected with an oscilloscope on the can bus lines. This is working and from that I can decode the message and extract the bitrate of the bus. The bus seems to be in 125kbit/s.
- I also have a canable dongle on the bus. The two equipment already has the 120 Ohm termination resistor so I've not put the one on the can dongle. When measuring the impedance between CAN-H and CAN-L I got the required 60 Ohm.
- The canable dongle is based on the slcan (serial-can) and uses an stm to do the can and connect as a usb cdc to the computer. When I start the monitoring on the canable the bus just fills up with retransmitted frame (or at least I think it is).
- I've put the dongle on listen only mode and correctly set the baudrate to 125k. With other baudrate I just have nothing from the dongle.
- I've try using only two canable on the bus and communication works fine. I can send and receive messages.

When I look at the frame at the scope I see that they are no longer acked, but I don't understand why.

My questions:
Since I have two working nodes on the bus, adding one shouldn't break the bus, isn't it? Since there is still one node to acknowledge the messages?
Is it possible that the bus is using a non-standard bit configuration for the canbus timing that would mess with the ack?

I can flash the candelight firmware instead of the slcan (https://github.com/candle-usb/candleLight_fw). I'll try that next. If that doesn't work I can still connect a debugger to the stm of the canable and try to find out what's going on.

I've put scope screen as attachment.

Thank you for reading my post, any lead is welcome

SoftTransistor

[SoftTransistor]

I found out. They were using a non-standard bitrate. What looked like 125k was in fact 120k.

I downloaded the source of the firmware (https://github.com/normaldotcom/canable-fw). Added the 120k option with the matching prescaler, recompiled, flashed the board and voila.

I didn't though that this was enought to mess up the canbus. I guess that the bitrate gap was enough to trigger retransmission. But I though that the silent mode and retransmission off was avoiding the issuen guess it wasn't.

Do I need to mark the post solved or something?

[HwAoRrDk]

That's weird. If your dongle was truly in listen-only mode, it should not have been possible for it to influence the bus in any way, and the worst is that you'd have got garbled data using the wrong bit rate.

I suppose it depends on how the dongle implements listen-only. If it's at the transceiver (some have a 'silent' pin that can be toggled), then that's pretty much guaranteed to not affect the bus; but if it's at the controller level, not so much.

[SoftTransistor]

Agreed.

It seems to be a mode implemented into the CAN module of the stm µC (https://github.com/normaldotcom/canable-fw/blob/master/Drivers/STM32F0xx_HAL_Driver/Inc/stm32f0xx_hal_can.h : 327). I never used stm CAN so I don't if it usually works. Maybe it says somewhere in an application note or errata that this mode is not working properly 

Anyway, the next step is to implement or modify an existing higher level can monitoring app/script, since none of the available one supports 120k baud with slcan

[hans]

125k vs 120k may not sound like much, but 125k will send 25 bits in the same time as 24 bits at 120k.
If a CAN frame is 8 bytes long, you have 111 bits on the wire (11-bit ID), and so it will easily shift the end of frame (which includes an 1-bit ACK) by 4 bits.

An UART is more resilient to these baudrate mismatches, as each frame is at most 8 data bits long. In that case you can quite reasonably be 0.5-1% off (may depend on oversample rate), e.g. by using a resonator. In all CAN bus standards I've read (which admittedly is limited), I've seen crystal-grade timing requirements (+/-100ppm)

[Fredderic]

An UART is more resilient to these baudrate mismatches, as each frame is at most 8 data bits long. In that case you can quite reasonably be 0.5-1% off (may depend on oversample rate), e.g. by using a resonator. In all CAN bus standards I've read (which admittedly is limited), I've seen crystal-grade timing requirements (+/-100ppm)

I was under the impression (CAN Bus has been on my TODO list for a while) that's what the bit stuffing is for — allowing CAN Bus to re-sync to the incoming signal at least every 6 bits, vs. 10 for regular UART, which would give it better timing tolerance, however, it also typically runs at a higher overall bit rate, and thus you still require a more precise timing overall.  (Regular UART seems to have comparable bit rates to CAN Bus's "low speed" mode.)

I'm not sure what that 5k difference does to the timing diagrams…  I think the calculation goes something like…  That's about 4% drift per bit, by 6 bits worst case (but also not uncommon), and the sample window usually aims to be about the middle third of the bit interval (I don't recall what the actual spec says on the matter)…  The two times I worked it out, I got different answers…  which puts 120k at best, uncomfortably close to the lower limit for a 125k base — that's supposed to be allowing for crystal offset, not intentional misuse.

Which seems a reasonable explanation for why it'd have been failing; I guess the CAN transceiver is seeing gibberish, and so asserting an error frame — "listen only" may not include "flat out ignore errors that could potentially go undetected by a critical node".

(If I have that wrong, I would appreciate correction by someone who actually knows what they're talking about here.)

[Siwastaja]

I was under the impression (CAN Bus has been on my TODO list for a while) that's what the bit stuffing is for — allowing CAN Bus to re-sync to the incoming signal at least every 6 bits, vs. 10 for regular UART, which would give it better timing tolerance, however, it also typically runs at a higher overall bit rate, and thus you still require a more precise timing overall.  (Regular UART seems to have comparable bit rates to CAN Bus's "low speed" mode.)

CAN uses this Synchronous Jump thing to re-align, but I have came across from several sources that there is some fundamental design flaw somewhere which renders resynchronization ineffective, I have forgot the details though. Crystal level (50-100 ppm) accuracy might not be needed, but I'd be very careful with 0.5-1% range clock error which is still workable with UARTs.