I have been trying to pass CAN frames between two different CAN busses using two different CAN channels on a STM32F746 MCU. The system always fails and freezes up in TX when it is supposed to be passing through CAN messages between the busses. The firmware shows the transmit messages are never clearing the CAN mailbox, which first pointed me to investigate TX. I have encountered some strange looking behavior on TX that I need help understanding.

Below is a basic schematic of the CAN bus system:


simulate this circuit – Schematic created using CircuitLab

The bus operates at 125kHz (8us bit time) Bit timing is as follows:

  • Internal MCU clock of 216MhZ, prescaled down 54MHz for the CAN module

  • Time quanta Tq = 500ns

  • SEG1 = 13

  • SEG2 = 2

  • SJW = 1

In the following picture of TX and RX during operation, the system is not working as intended. RX looks healthy, but TX is supposed to be transmitting messages from the other bus. It is not. It appears to be ACKing however. enter image description here

Next is a different capture from the same probing session. It gets weird! TX seems to jump in and fail in a way I don't understand. enter image description here Zooming in... enter image description here

TX appears to be jumping in, maybe to ACK, but ends up truncating the end of the frame to shorten that last bit by over half of the normal 8us it should be. The last bit on RX is truncated to only 3.2us. TX then goes dominant for 4 or so bits inexplicably.

Finally, here is a zoomed in image of the 'normal' looking ACK from earlier. It also appears to be shortened to about 6.6us. enter image description here

What could be causing this behavior?

I cannot figure out any mechanism which would lead to this type of error. Is it failing acknowledgments, arbitration, bit timing, something else, or a mix of all?

I have debugged the following:

  • The transceivers are good

  • The CAN bus signals all look healthy and square

  • I have tried different termination configurations and resistor values

I would greatly appreciate any insight or guidance on how to proceed with debugging from here.

Thank you!


2 Answers 2


In your first image you expect TX to transmit messages from the other bus. But it does not even try, which may suggest the buffer for incoming messages is empty or the controller already went error passive. What you can see is high bus utility due to the minimum time between frames.
Yet they are acknowledged correctly.

In your second image you are looking at an error flag at the end of the frame. This might suggest CRC failure. Please check the error counters.

It's a good thing CAN bus controllers have sophisticated error counters. So you can go an look which error occurred by looking the status registers.

Please check:
CAN transmit status register (CAN_TSR)
CAN error status register (CAN_ESR)

It's also more valuable to look at the CAN bus with more then only an oscilloscope. See if you can acquire at least a logic analyzer (with protocol decoding). Or an analyzer from Kvaser/Vector/Peak.


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 about this issue


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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