2021-07-30 02:01 AM
CubeMX prevents the user from selecting certain (valid) CANFD bit timing configurations.
"Nominal Time Seg1" and "Nominal Time Seg2" are affected: These should have a minimum value of 1, but instead CubeMX only allows "2" as minimum value.
This is problematic because it prevents the very common bit timing configuration 1 (Sync, fixed) + 6 ("Nominal Time Seg1") + 1 ("Nominal Time Seg2": This is where the problem shows).
That configuration is highly desirable because it has the sample point at 87.5% which is desired by many higher level protocols and it also works out nicely for almost every common baudrate from a 8MHz clock just by changing the prescaler.
Current workaround is to manually change this in the generated code; this works, but the changes will need to be re-done every time after running the code-generation which is super annoying.
Affected (also all older version AFAIK):
STMCubeMX: 6.3.0
STMCubeIDE: 1.7.0
Both using STM32Cube FW_H7 V1.9.0
Occured with: STM32H730VBH (TFBGA100 Package)
2021-08-05 06:30 AM
Hello @Wolfgang Pupp
Thanks for your post,
Actually, CubeMX gives user the ability to select values which are recommended in HAL drivers , I can see under stm32h7xx_hal_fdcan.h :
uint32_t NominalTimeSeg1; /*!< Specifies the number of time quanta in Bit Segment 1.
This parameter must be a number between 2 and 256 */
uint32_t NominalTimeSeg2; /*!< Specifies the number of time quanta in Bit Segment 2.
This parameter must be a number between 2 and 128 */
Could you please check from FW side @Imen DAHMEN ?
Thanks
Khouloud
2021-08-05 07:36 AM
I'm fairly positive that the lower limit should be 1, also for NominalTimeSeg1.
This is because the reference manual says "valid values are 0 to 255" (NTSEG1) and "0 to 127" (NTSEG2)
See "61.5.7 FDCAN nominal bit timing and prescaler register (FDCAN_NBTP), page 2580".
That is exactly the register where these values end up in, they are just decremented by 1 (because similarly to prescaler registers, a raw value of "0" inside the register means 1 time quantum).
@Khouloud ZEMMELI Thx for quickly investigating all my complaints! :thumbs_up:
2021-11-12 03:58 AM
It is also present in stm32G4 HAL. I'm thinking that it is a bug. Even if you look at assertions in code
in stm32g4xx_hal_fdcan.h they something different then comment.
#define IS_FDCAN_NOMINAL_TSEG1(TSEG1) (((TSEG1) >= 1U) && ((TSEG1) <= 256U))
#define IS_FDCAN_NOMINAL_TSEG2(TSEG2) (((TSEG2) >= 1U) && ((TSEG2) <= 128U))
Regards,
Pawel
.