You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CAN driver doesn't properly report errors. It always returns 1 as the write was successful, then turns out it wasn't
and errors are accumulated (not sure what these errors are, it's not written in the documentation and people
seem to have different ideas) and only then it starts to return 0. I assume it writes the frame to mailbox (according to source code) and happily returns 1, but then the hardware cannot actually send it and gives tderror after to
many attempts. This seems to only happen on a busy line.
The current solution is to just restart the tx line if that happens, at least this is all you can do with the
given API.
And my question is exactly that, how do you make a reliable CAN transmission with this API, which doesn't report errors.
With the given API functions it seems like you have to send frame, monitor tderror() and hope that it works.
Target(s) affected by this defect ?
STM32L486x, but should affect all STM32L4 as they don't use fifo, which probably has similar issues by looking at the code.
Toolchain(s) (name and version) displaying this defect ?
arm gcc v10.3.1
What version of Mbed-os are you using (tag or sha) ?
mbed-os-6.17.0
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
dfu-util 0.9
How is this defect reproduced ?
Attach the device to a busy bus and keep trying to send frames.
The text was updated successfully, but these errors were encountered:
Description of defect
CAN driver doesn't properly report errors. It always returns 1 as the write was successful, then turns out it wasn't
and errors are accumulated (not sure what these errors are, it's not written in the documentation and people
seem to have different ideas) and only then it starts to return 0. I assume it writes the frame to mailbox (according to source code) and happily returns 1, but then the hardware cannot actually send it and gives tderror after to
many attempts. This seems to only happen on a busy line.
The current solution is to just restart the tx line if that happens, at least this is all you can do with the
given API.
And my question is exactly that, how do you make a reliable CAN transmission with this API, which doesn't report errors.
With the given API functions it seems like you have to send frame, monitor
tderror()
and hope that it works.Target(s) affected by this defect ?
STM32L486x, but should affect all STM32L4 as they don't use fifo, which probably has similar issues by looking at the code.
Toolchain(s) (name and version) displaying this defect ?
arm gcc v10.3.1
What version of Mbed-os are you using (tag or sha) ?
mbed-os-6.17.0
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
dfu-util 0.9
How is this defect reproduced ?
Attach the device to a busy bus and keep trying to send frames.
The text was updated successfully, but these errors were encountered: