stm32: canio: duplicate packet transmission

[jepler]

After some bus problems, canio sends packets multiple times instead of just once.

Using the "ack" demo from adafruit/Adafruit_Learning_System_Guides#1293 start the listener and then the sender and see that everything is in a steady state.

Pull out one of the bus wires and then plug it back in after a second or two.

Notice that now the receiver seems to get each packet 3 times and the receiver seems to get each ACK packet 3 times.

[jepler]

This is likely to be specific to stm32f405 implementation, and appears to be a problem on the sending side but that's just a guess. 3 also happens to be the number of transmit buffers.

[Kheirlb]

Also seeing this issue.

[Kheirlb]

I'm thinking about taking a look at this canio issue. I know this issue is old, but can @jepler, @tannewt, @dhalbert, or anyone on the CircuitPython team point me in the right direction? I'm about to switch to Arduion/C just to avoid this bug.

[tannewt]

I'm thinking about taking a look at this canio issue. I know this issue is old, but can @jepler, @tannewt, @dhalbert, or anyone on the CircuitPython team point me in the right direction? I'm about to switch to Arduion/C just to avoid this bug.

We'd love help. You can chat with us in #circuitpython-dev on Discord and we can help with any bumps you hit. Build instructions are here: https://learn.adafruit.com/building-circuitpython The STM canio implementation is done here: https://github.com/adafruit/circuitpython/tree/main/ports/stm/common-hal/canio

[Kheirlb]

To supplement the original report, here is a screenshot of the (recurring?) duplicate transmission issue.

Thanks for the build instructions and pointer tannewt! I'll start poking at the sender side code. Hopefully I can make a little contribution here :)

EDIT: Doing these tests on 8.2.10

1. I repeated this test with both microcontrollers on the official 8.2.10 from https://circuitpython.org/board/feather_stm32f405_express/. Same result as whatever config I started in.
2. I also repeated with local checkout of tag: 8.2.10. Same result. Wrote 1129984 bytes to build-feather_stm32f405_express/firmware.uf2 (flashed with the .bin output)

[Kheirlb]

This is likely to be specific to stm32f405 implementation, and appears to be a problem on the sending side but that's just a guess. 3 also happens to be the number of transmit buffers.

@jepler and team, where is this "3" number for transmit buffers defined? I'm looking at some of your later commits for common_hal_canio_can_send: e5a0af9 and eed3387

I think you are maybe talking about the 3 transmit "mailboxes".

[Kheirlb]

I think after each tx attempt, we can ensure all "mailboxes" are clear again? Found an implementation here.

This is a substitute for e5a0af9

    // Wait until all mailboxes are free again.
    while (HAL_CAN_GetTxMailboxesFreeLevel(&self->handle) != 3) {
        RUN_BACKGROUND_TASKS;
    }

Unfortunately, this seems to make can.send blocking... maybe that is okay? I assume can.send should not be blocking...