Electronics > Microcontrollers

Canbus retransmissions error.

(1/2) > >>

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 :palm:

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)

Navigation

[0] Message Index

[#] Next page