2
\$\begingroup\$

I am designing a system to 'hack' into a CAN bus. My first idea was to split the target CAN bus, terminating both ends into isolated CAN transceivers, and use a MCU to pass packets between the buses while altering values inside the packets. Below is a rough picture of the setup:

Hand drawn system diagram

My problem is that while connected to the target CAN bus, the system fails to transmit on either CAN bus. In the program I can see it is receiving, but the MCU gets stuck in a loop of failed transmissions.

The weird part is that I can prove the code and hardware are all viable in a different environment. When I hook up the hardware to a test rig I made using a couple of development boards and a power supply, it works well! The packets from both devices are seen on both buses. The packet bits look healthy and square. I am at a loss figuring out what specifically is different about the environments on my desktop and on the target CAN bus that make it break.

System details follow:

MCU - STM32F746ZGT6

Isolated CAN transceivers - ADM3054

Bus speed - 125kHz (confirmed with oscilloscope and CAN sniffer tool)

I'd really appreciate help thinking through this system design, and understanding how it might cause CAN transmissions might fail.

Thanks!

EDIT: Upon farther thought, I think I realize the area to focus on is between the TxR and the MCU. If the MCU is refusing to declare a successful transmission, than it must think something wrong is happening on the bus. It can only interact with the bus via TX and RX. I will scope TX and RX to see if I can see any weird errors, possibly caused by reflections or something interfering with RX during transmission?

EDIT 2: added schematic and layout image enter image description here enter image description here

\$\endgroup\$
  • \$\begingroup\$ Possibly something to do with arbitration? \$\endgroup\$ – pericynthion Jun 25 at 17:07
  • \$\begingroup\$ the Can bus is continually monitored, by a transmitting node, to ensure its ones and zeros are properly imposed onto the buss. Any significant propapation delays will cause that node to assume a collision, and it will turn off. \$\endgroup\$ – analogsystemsrf Jun 25 at 17:48
  • \$\begingroup\$ @analogsystemsrf what magnitude of delay might affect the system? Given 125kHz, the bit time is 8us. The datasheet for the transceivers describe a propagation delay for Tx to Bus active of 70ns. \$\endgroup\$ – ztan Jun 25 at 18:06
  • \$\begingroup\$ @analogsystemsrf At 125kbps you should be able to handle many hundred meters of wire length. Every bit has a "dead" propagation delay period from the active edge until the bit is sampled, suitable for the given baudrate. Given that the sample point is placed somewhere near the ideal recommended position of 87.5% of the bit length, you should have some >500m of total bus length at 125kbps. \$\endgroup\$ – Lundin Jun 27 at 11:34
1
\$\begingroup\$

According to your schematic, you broke up the bus in two and there's no termination anywhere. You get the wrong impedance instead of the expected 60 Ohm. Before each transceiver on the "hack" device, you need terminating resistors of 120 Ohm between CANH and CANL.

In addition, the "hacker" MCU's CAN controller must actively participate on the bus, you can't have it set to listen-only or loopback mode. Otherwise the other node on the bus will have none to speak with and eventually go error passive mode.

\$\endgroup\$
  • \$\begingroup\$ I have updated my post to add a schematic and layout image. I did add termination, referencing the application designs in the datasheet of the transceiver. Two series 60 ohm, with a 4.7nF cap in the middle. Looking into it before I implemented it, this LPF configuration apparently helps reduce reflections. \$\endgroup\$ – ztan Jun 27 at 16:36
0
\$\begingroup\$

I have finally found a solution that works. After exhausting every possible hardware debug possibility, I recreated the system using STM Nucleo boards. After 30% of nucleo boards worked and the rest failed, with identical hardware setup, I was lead to investigate the only remaining variable I could think of, which was the variance on the MCU internal resonator. After activating my external high accuracy resonator, and lowering the entire application master clock speed, I was able to get something working. What I learned is clock integrity is VERY important in this type of application.

Resources I used to solve this:

For clock speed calculations: NXP CAN bit timing application notes

Link to another related post

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.