-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Wrong algorithm for CAN timing settings in can_api.c (STM32G474RE) #15309
Comments
@chdelfs thank you for raising this issue.Please take a look at the following comments: Could you add some more detail to the description? A good description should be at least 25 words. NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'. This indicates to us that at least all the fields have been considered. |
My suggestion is that can_api.c is modified in line 312: After changing the Mbed source as above, I could successfully use CAN bus on NucleoG474RE. |
cc @ARMmbed/team-st-mcd |
Would you send a pull request addressing this? |
PR is created: |
Description of defect
Algorithm for calculating the CAN bus timing settings in method int can_frequency(can_t *obj, int f) appears to be wrong.
It differs from the method applied in _can_init_freq_direct(can_t *obj, const can_pinmap_t *pinmap, int hz) which yields - to my understanding - the correct settings.
The main difference is in the file targets/TARGET_STM/can_api.c in line 145 vs line 312:
can_init_freq_direct() uses macro IS_FDCAN_NOMINAL_TSEG1 whereas can_frequency() uses macro IS_FDCAN_DATA_TSEG1 for calculation of the nominalPrescaler. Macro IS_FDCAN_DATA_TSEG1 is meaningful only for FDCAN which is not supported by Mbed.
The impact is that the CAN bus timing settings lead to a deviation from the desired CAN transmission speed.
Other CAN controllers will not be able to receive CAN messages and - therefore- will not acknowledge CAN transmissions.
This leads to transmission errors: either other parties on the CAN bus send error frames or they do not send an acknowledge
and finally this leads to a "bus off" state in the STM32G4 CAN controller.
Target(s) affected by this defect ?
Toolchain(s) (name and version) displaying this defect ?
What version of Mbed-os are you using (tag or sha) ?
6.16.0
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
mbed-cmake
How is this defect reproduced ?
I faced the issue in https://forums.mbed.com/t/no-successful-can-bus-sending-with-nucleog474re.
The text was updated successfully, but these errors were encountered: