Incoming messages randomly repeating, getting stuck in buffer?

[ironhal0]

Hello. I am testing your code on a Nucleo-STM32F446RE with attached SN65HVD230 module. I am testing out your READ example code with no modifications, sending test messages to the STM32 from my USB CAN Analyzer software. I am seeing a lot of random repeats of incoming CAN messages. Sometimes the incoming message is processed and displayed only once, but a lot of the time the message is repeated somewhere between 3 and 25 times (or more). As an example you can see from the attached screenshots that I sent three individual messages from my Canalyzer unit, a few seconds apart, and you can see how many times the code repeated the messages. From observation, the issue seems more severe when the message is all or mostly zero values.

I have tested my hardware setup with 2 other CAN libraries/examples, including this one: https://github.com/nopnop2002/Arduino-STM32-CAN, and with neither of those other libraries do I see any repeats of messages. So I assume my hardware is okay. However your implementation is far more elegant and I'd much prefer to use your code if I can figure out the issue. Have you seen this happen, and any idea why this might be happening for me?

Thanks for any insight you can provide!

JW

[pazi88]

Hi!

I haven't seen that problem. Though I haven't tested on F446RE. I don't own one. What core version are you using. Could be also something that has been introduced in newer core. I need to test with latest one if there is some problems like that.

[ironhal0]

I'm on the latest 2.3.0 version of the official STM32duino core: https://github.com/stm32duino/Arduino_Core_STM32

If you could test with that version, and test receiving some frames of all zero values, I would love to know if you're seeing the same issues I am... if not maybe it's some problem specific to my setup. Which CAN transceiver chips do you use?

Thanks!

[pazi88]

Thanks. I'll try with that version. I seemed to still have 2.1.0 version and didn't see the issue with that, when I tried today. I use mcp2551.

BTW in this library the receive part is also interrupt based. It will catch all the frames on the bus. The other libraries work by polling the bus and I have had problems with those missing majority of the frames if the bus is busy enough. So it could be also that others aren't seeing those multiples. But still. More likely case is that there is bug somewhere 😁

[ironhal0]

I have just tested my Nucleo-STM32F446RE with an MCP2551 transceiver, and I'm still seeing the same duplicate/multiple issues, same as with the SN65HVD230 transceiver. However, I also tested both transceivers on my Nucleo-STM32F29ZI board with exactly the same code, and am seeing absolutely ZERO multiples or duplicates. So apparently something about the F446RE is causing the issues.

Any insight into how I might go about diagnosing that? Thanks!

[ironhal0]

Without knowing why it's happening or what a real solution would look like, I at least seem to have a workaround figured out. For the F446RE with STM32duino core, the Sysclk is set at 180MHz by default and the APB1 clock divider is set at /4 by default. That means the APB1 is running at 45MHz. For whatever reason a 45MHz APB1 clock is incompatible with the CAN timing given the way it works with your code. In experimenting I found two combinations of Sysclock and APB1 divider values that make this issue go away completely on the F446RE. I can either set my APB1 divider to /16, which runs APB1 at 11.25MHz...or I can set my Sysclk to 168MHz and leave my APB1 divider at /4, which gives me an APB1 of 42MHz (which is the same timing as my F429ZI, which does not exhibit the issue at all...so that makes sense). For now I'm going to go with the latter and just run the board at 168MHz.

[pazi88]

Pretty weird issue indeed, but good that you found workaround. I need to see if there is problems in the calculations etc. with that 45MHz APB1 frequency.

[pazi88]

I will close this issue now. The issue should be currently fixed in the library.