Wrong logic for TX vs RX at EOF

[kentindell]

The CAN spec requires that the transmission of a message is complete at the end of the last bit of EOF, but that the reception of a message is complete at the end of the second-to-last bit of EOF (see 11989 section 10.7). It has to be this way because of CAN's atomicity property. There is a consequential feature of the protocol of the Double Receive Problem. See here for more on that: https://kentindell.github.io/2020/07/11/can-atomic-multicast/

[KevinOConnor]

Can you provide some additional information on why you believe this is not working correctly? I did attempt to make that work (see the check in data_state_update_eof1() in can2040.c). Admittedly, it is a little difficult to test that particular code path.

-Kevin

[kentindell]

I can help you test that code path with the CANHack toolkit, which is designed to inject these conditions:

https://github.com/kentindell/canhack/tree/master/src

There's also a MicroPython API and a firmware drop for the v1.18 MicroPython firmware on the RP2040, so it's fairly easy to set up an attack (you might need to change the transceiver pins from the defaults for the CANPico).

[kentindell]

In terms of the logic, I see you're not throwing errors and are post-processing the received signal. That corner cutting kind of works elsewhere in the frame but it doesn't apply here because of the way CAN's atomicity property works: signalling for a retransmit must happen in exactly the right place to bring all the controller into sync and for a retransmit to happen.

[KevinOConnor]

I can help you test that code path with the CANHack toolkit, which is designed to inject these conditions:

Thanks.

In terms of the logic, I see you're not throwing errors

The can2040 code never generates error frames. This is a known limitation of the project. https://github.com/KevinOConnor/can2040/blob/master/docs/Features.md#protocol-details

In regard to this issue report, it would help to have further details. Can you confirm that you are running can2040 locally and are able to reproduce a case where can2040 does not handle the EOF bits correctly? What frame is not being processed correctly? What is the incorrect behaviour (for example, does can2040 internally pass on a received message that it should not have, does can2040 fail to retransmit a message that it should have)?

Cheers, -Kevin

[kentindell]

This atomicity issue here is actually a consequence of not generating errors: the reason for the one bit time difference between TX and RX is there precisely to achieve atomicity. You should probably look again at that error restriction because the error handling in CAN is an intrinsic part of a lot of the properties of CAN: it's not just about the receiver discarding a bad frame like with Ethernet. For example, all the logic for the ACK bit is dependent on there being error signalling (and the logic for TEC and error passive is built the way it is because of the ACK field).

[KevinOConnor]

I understand the intent of the "error active" state (in short, it increases the confidence that a bus message is either received by all nodes or zero nodes). Alas, I don't think "error active" support in can2040 is plausible - it requires strict timing (response time in a couple of hundred nanoseconds) and notable state tracking. It appears too complicated for the PIO and too timing intense for the ARM core.

I do think the can2040 code provides significant utility even though it only supports "error passive" state.

I'm not really sure the state of this particular ticket. To the best of my knowledge the can2040 works as intended (7 passive eof bits for tx success, first 6 passive eof bits for rx success); lack of "error active" support is a documented limitation.

Cheers, -Kevin

[github-actions[bot]]

Hello,

It looks like there hasn't been any recent updates on this github ticket. We prefer that only tickets actively being worked on be listed in an "open" state. Feel free to provide an update on this ticket. Otherwise the ticket will be automatically closed in a few days.

Best regards,

~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.