Skip to main content
David Pekin
David Pekin
Senior
March 12, 2018
Solved

CAN message repeats flood bus

  • March 12, 2018
  • 4 replies
  • 2064 views
Posted on March 12, 2018 at 18:30

Hello,

I have a system using the CAN bus with a STM32F303 talking to a motor controller and a STM32F722 silently monitoring the F3 / motor controller communications.  It seems to work relatively reliably.

While bringing up the system, I noticed that sometimes the F3 would send a command and then unexpectedly that command would be repeated on the bus a bazillion times about as fast as is possible on the CAN bus.  I'd need to reset the F3 to stop the TX repeats.   I suspect there's a wiring or terminating resistor issue but am not exactly sure at this point. 

Is continued TX retries typical CAN modality when a TX fails?  If so, is this configurable in the HAL CAN implementation?

Thanks.

    This topic has been closed for replies.
    Best answer by David Pekin
    Posted on March 12, 2018 at 23:32

    I don't think anything would acknowledge that packet since the target device was off line.   But it gets stranger and stranger. 

    So I changed the target ID to address a node that was on the CAN bus to test the theory that the repeats were because the device wasn't there.  When I ran that code, the same millions of retries occur...  Hmm. 

    So I repower everything again to see if the whole CAN bus is failed.  The same thing happens after repower. 

    While inspecting the boards, I notice that one of the I2c lines (SDA PC.9) was pulled off by the scope probe.   When I reattached that line and went back to debug the repeating TX packets on the CAN bus,  I was not able to repeat the problem.  (Note that I have been looking at this issue for more than an hour and it was very repeatable.)  So,  even though I couldn't believe that the repeating packets had anything to do with the I2C SDA line connection, I removed the SDA line and tried to get the repeating packets problem back.  Now, no matter what I try, I can't get the problem to repeat itself....

    EUREKA!  FOUND IT!!!

    If the CAN TX and RX lines are shorted across each other on the F3 board prior to the CAN driver chip, somehow the CAN signal created by the short causes this phenomenon...   It is very repeatable.  

    4 replies

    David Pekin
    David PekinAuthor
    Senior
    March 12, 2018
    Posted on March 12, 2018 at 22:16

    I've been able to reproduce the continuous TX error.  In certain cases, after the CAN bus has been initialized, the first can TX package gets continuously transmitted for some reason.  There's a HAL_CAN_Transmit_IT call and it returns a HAL_OK return value yet the system starts to resend the CAN packet over and over again about every 100-150us.  In this current setup the device with the destination ID for the packet is not on the bus.  Is this normal CAN bus behavior?

    Tesla DeLorean
    Tesla DeLorean
    Guru
    March 12, 2018
    Posted on March 12, 2018 at 22:44

    Does anything acknowledge the packet?

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    David Pekin
    David PekinAuthorBest answer
    Senior
    March 12, 2018
    Posted on March 12, 2018 at 23:32

    I don't think anything would acknowledge that packet since the target device was off line.   But it gets stranger and stranger. 

    So I changed the target ID to address a node that was on the CAN bus to test the theory that the repeats were because the device wasn't there.  When I ran that code, the same millions of retries occur...  Hmm. 

    So I repower everything again to see if the whole CAN bus is failed.  The same thing happens after repower. 

    While inspecting the boards, I notice that one of the I2c lines (SDA PC.9) was pulled off by the scope probe.   When I reattached that line and went back to debug the repeating TX packets on the CAN bus,  I was not able to repeat the problem.  (Note that I have been looking at this issue for more than an hour and it was very repeatable.)  So,  even though I couldn't believe that the repeating packets had anything to do with the I2C SDA line connection, I removed the SDA line and tried to get the repeating packets problem back.  Now, no matter what I try, I can't get the problem to repeat itself....

    EUREKA!  FOUND IT!!!

    If the CAN TX and RX lines are shorted across each other on the F3 board prior to the CAN driver chip, somehow the CAN signal created by the short causes this phenomenon...   It is very repeatable.  

    AvaTar
    AvaTar
    Senior III
    March 13, 2018
    Posted on March 13, 2018 at 07:12

    A frame is repeated, if an error is detected in the End-Of-Frame field of the CAN message.

    Not sure how your SDA line introduced an error here.

    And normally, the transceiver should go into error-passive mode, eventually (i.e. 256 errors).

    Terms & ConditionsAccessibility statement