Fix for calculating CAN timing settings for STM32 #15317
Conversation
NominalPrescaler value needs to be as high as possible to ensure a good approximation of the target CAN speed. Previous usage of macro IS_FDCAN_DATA_TSEG1 refers to (unsupported by Mbed ) FDCAN CAN controller settings and leads to too low prescaler values. Usage Macro IS_FDCAN_NOMINAL_TSEG1 yields optimum results. See also correct macro usage in line ARMmbed#158.
ciarmcom
added
the
release-type: patch
|
@chdelfs, thank you for your changes. |
targets/TARGET_STM/can_api.c
Outdated
| @@ -335,7 +335,7 @@ int can_frequency(can_t *obj, int f) | |||
| // !When the sample point should be lower than 50%, this must be changed to | |||
| // !IS_FDCAN_DATA_TSEG2(ntq/nominalPrescaler), since | |||
There was a problem hiding this comment.
Should this comment be updated ?
There was a problem hiding this comment.
I assume this shall be now IS_FDCAN_NOMINAL_TSEG2 ?
|
IMHO, the comment can or should be updated as well. See also the equivalent comment in function can_internal_init() which partially duplicates the code from can_frequency(). |
Will you update this pull request? |
|
Shall this be updated so we can proceed with integration? |
Modified comment as discussed.
|
CI started |
Jenkins CI Test : ❌ FAILEDBuild Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & ArtifactsCLICK for Detailed Summary
|
Jenkins CI Test : ✔️ SUCCESSBuild Number: 2 | 🔒 Jenkins CI Job | 🌐 Logs & ArtifactsCLICK for Detailed Summary
|
|
Hi all, |
You are not! Thanks for bringing this up. I merged it. |
mbedmain
removed
release-type: patch
NominalPrescaler value needs to be as high as possible to ensure a good approximation of the target CAN speed.
Previous usage of macro IS_FDCAN_DATA_TSEG1 refers to (unsupported by Mbed ) FDCAN CAN controller settings and leads to too low prescaler values.
Usage Macro IS_FDCAN_NOMINAL_TSEG1 yields optimum results.
See also correct macro usage in line 158.
Summary of changes
Replaced macro IS_FDCAN_DATA_TSEG1 by IS_FDCAN_NOMINAL_TSEG1 to ensure that nominalPrescaler is calculated correctly.
Impact of changes
Method frequency() of CAN API can safely be used.
If no fix is applied, any call to this method will lead to improper CAN bus settings and CAN transmissions are not reliable or do not work at all.
Migration actions required
No
Documentation
None
Pull request type
Test results
The bug becomes visible as soon as the method frequency() of the CAN API is used, even if the default frequency of 100kHz is applied.
If no fix is applied, STM32G4 device will enter "bus off" state right after attempting to send CAN frames.
Reason is that the CAN timing settings will lead to a CAN bus frequency of the CAN Controller which deviates by 2% from the target frequency (for 100kHz target frequency). With a fix, this deviation is 0.2%.
I assume that so far CAN related tests used the default timing settings, but never checked the impact of using the method frequency().
Details are provided in https://forums.mbed.com/t/no-successful-can-bus-sending-with-nucleog474re/17449/12.
Reviewers