timeout error when writing

[photon-delight]

I am experiencing an issue when writing to the device :

root@beaglebone:~/arm# ./canbin.sh
[21:09:03.614] main INFO: Connecting target
[21:09:03.621] stm32 INFO: Bootloader initialized
[21:09:03.642] stm32 INFO: Bootloader version: 2.0
[21:09:03.651] stm32 INFO: Read protection: 0x0000
[21:09:03.665] stm32 INFO: Chip ID: 0x0418 - STM32F105xx/107xx
[21:09:03.667] main INFO: Connected
[21:09:03.955] main INFO: Writing memory at 0x08000000:15940
[21:09:03.958] stm32 INFO: Progress: 0%
[21:09:05.181] main ERROR: Writing error: Receiving timeout

While reading doesn't have any issues :

root@beaglebone:~/arm# ./canread.sh
[21:16:03.951] main INFO: Connecting target
[21:16:03.959] stm32 INFO: Bootloader initialized
[21:16:03.981] stm32 INFO: Bootloader version: 2.0
[21:16:03.990] stm32 INFO: Read protection: 0x0000
[21:16:04.003] stm32 INFO: Chip ID: 0x0418 - STM32F105xx/107xx
[21:16:04.006] main INFO: Connected
[21:16:04.007] main INFO: Reading memory at 0x08000000:512
[21:16:04.009] stm32 INFO: Progress: 0%
[21:16:04.092] stm32 INFO: Progress: 50%
[21:16:04.137] stm32 INFO: Progress: 100%
[21:16:04.140] main INFO: Successful
[21:16:04.164] main INFO: Disconnecting target
[21:16:04.166] main INFO: Disconnected

[photon-delight]

Could this possibly be due to the socketCAN txqueuelen setting?

[marcinbor85]

Hi. Do You check if the sectors which You try to write are write protected? Regarding the txqueuelen I don't think so. Also, You could debug this case with logic analyzer on the bus. MB niedz., 2 maj 2021 o 14:29 Ryan B ***@***.***> napisał(a):

…

Could this possibly be due to the socketCAN txqueuelen setting? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRS2EIHUTDT44X766PTYFDTLVARJANCNFSM43LFALCA> .

[photon-delight]

Thank you Marcin,

I have now managed to program small files successfully... 256 bytes and sometimes 512 bytes.. but that seems to be the max. That is why I thought it may be due to a buffer overflow (or something to that effect) on the socketCAN side. Changing txqueuelen didn't have any effect - as you mentioned.

My guess right now is that its an issue with the CAN timing on the beaglebone side...

I'm happy to close this issue if you feel it would appropriate

[tobylindsay1]

I am currently experiencing the same issue. Was a solution ever found for this? I am using a stm32f412 and a peak adapter as my interface.

[photon-delight]

I didn't ever solve this issue... please let me know if you ever manage to resolve it.

[CaptainJack42]

I'm currenctly facing the same issue, from a quick glance it indeed appears to be an issue with the speed at which messages are sent, so i guess this might be an issue with the txqueuelen, adding a short delay after each 8 byte write (i'm currently using 0.1sec but thats just a really quick test) it is working as expected, but it is really slow (obviously).

I'm testing on an L486 with a CANable adabter.

I'll investigate further and report back.

[photon-delight]

Its great that you at least found a solution which works. Is there any more info from your investigation?

[QuickRecon]

I found that I had this issue, and it was fixed by increasing the SJW on the socketcan interface to 2 (from the default value of 1)