-
Notifications
You must be signed in to change notification settings - Fork 766
-
Notifications
You must be signed in to change notification settings - Fork 766
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Panda aborts CAN send on NACK #1922
Comments
I believe we intend to infinitely retry sending messages that get into the TX ring buffer (since any device on the bus will ACK) as mentioned in #421 and #968. I think silently dropping a message that makes it into the TX ring buffer is always bad. It seems like we need a test that ensures we retry until ACK. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I noticed the panda no longer retries sending a message when it's not ACKed. I'm opening this issue to check if this is intentional.
I think this behavior was introduced in this PR: https://github.com/commaai/panda/pull/1067/files. An interrupt was added for
CAN_IER_LECIE
, which includes getting a NACK. This in turn triggers an abort of the send inllcan_clear_send
.If this is intentional behavior, it's probably cleaner to put the CAN controller in "Time Triggered CAN" mode where retries are disabled by default, and no manual cancellation is necessary. If this is intentional I would also like to suggest to return the message as "blocked/error" to the user, because now the message disappears into thin air.
Quick hack to bring back retry behavior on F4 pandas, but there are probably other errors that need to be retried as well (e.g. form error). pd0wm@d1fc60b
The text was updated successfully, but these errors were encountered: