SDO download fails with message flood

[dakhnod]

Using candump, I often times observe the following behaviour on the CAN bus when my PI (using python-canopen) tries to upload an SDO to Node-id 3 (stm32 / CANOpenNodeStm32).

can0  603   [8]  21 00 70 01 40 00 00 00
can0  583   [8]  60 00 70 01 00 00 00 00
can0  603   [8]  00 00 80 00 C0 C0 00 00
can0  583   [8]  20 00 00 00 00 C0 00 00
can0  583   [8]  00 00 00 00 00 20 00 00
can0  583   [8]  00 20 00 00 00 00 00 00
can0  583   [8]  00 00 00 00 00 00 00 20
can0  583   [8]  00 00 00 00 00 20 00 00
can0  583   [8]  00 00 00 00 20 00 00 00
can0  583   [8]  00 00 00 20 00 00 00 00
can0  603   [8]  10 00 00 00 00 00 00 00
can0  583   [8]  30 00 00 00 00 00 00 00
can0  583   [8]  30 00 00 00 30 00 00 00
can0  583   [8]  00 00 00 00 30 00 00 30
can0  583   [8]  00 00 30 00 00 00 00 30
can0  583   [8]  00 00 30 00 00 30 00 00
can0  583   [8]  00 00 30 00 00 00 00 00
can0  583   [8]  00 00 30 00 00 00 30 00
can0  583   [8]  00 00 30 00 00 00 30 00
can0  583   [8]  00 00 30 00 00 30 00 00
can0  583   [8]  00 00 30 00 00 00 00 00
can0  083   [8]  00 00 00 01 00 00 00 00
can0  703   [1]  05
can0  603   [8]  80 00 00 00 00 00 04 05
can0  603   [8]  0F 00 00 00 00 00 00 00
can0  603   [8]  0F 00 00 00 00 00 00 00
can0  583   [8]  80 00 70 01 01 00 04 05

The way I see it, the node is putting out garbage on the bus starting from line 5.
This then disrupts the canopen stack on the PI and the SDO download fails.

Is there any obvious error in my thinking?
Is this a common error that is easily fixed?
Do those multiple messages from the node have any purpose, or are they really just a glitch?

Any help will be apreciated.

[sveinse]

It seems the node is misbehaving by sending multiple responses (and with different payload). The SDO operation have a regime where some of the messages must toggle a bit (the MSB of the first byte). I believe the SDO client in canopen will error if it encounters a node that doesn't adhere to this.

[dakhnod]

I forgot to close this, sorry.

Turns out I used the STM32 internal clock for CAN, which is not accurate enough. This messed up the CAN Bus.

Thank you work the help and work.