Bug on HAL_CAN_ConfigFilter for stm32f105 CubeMX

[Marco1]

Posted on February 16, 2016 at 12:10

When you set the filters for can2, software try to set the registers at base 0x4006800 + 0x200 instead of  0x4006400 + 0x200.

Using handle hcan its correct ?  MODIFY_REG(hcan->Instance->FMR                         ,             CAN_FMR_CAN2SB                              ,             CAN_FMR_FINIT                              |             (uint32_t)(sFilterConfig->BankNumber << 8)   );Sorry for my englishMarco

[Nesrine M_O]

Posted on February 18, 2016 at 16:28

Hi Marco,

•According to the memory map in the STM32F105 datasheet the bxCAN2 base address is 0x4000 6800 witch it is aligned with the stm32f105xc.h file “#define CAN2_BASE             (APB1PERIPH_BASE + 0x6800)â€�•So could you please explain a bit more what kind of problem you are facing â€¢Which CubeMX version are you using? If you are using an old version please try to use the latest -Syrine-

[Marco1]

Posted on February 18, 2016 at 17:16

Hi, 

i use stm32CubeMX 4.13.0 with library package 1.13.1.When you call HAL_CAN_ConfigFilter with handle of CAN2, the code try to set register at (CAN2 base) 0x4006800 + 0x200 (CAN_FMR), but in your pdf i read this24.9.5 bxCAN register mapRefer to Section: Memory map for the register boundary addresses. In connectivity linedevices, the registers from offset 0x200 to 31C are present only in CAN1. So i think is not possible write o read CAN_FMR, CAN_FM1R, CAN_FS1R, CAN_FFA1R, CAN_FA1R with CAN2 base address.Sorry again for my englishRegards

[glooom]

Posted on July 13, 2016 at 10:52

Confirm this bug, HAL_CAN_ConfigFilter does not work with hcan.Instance = CAN2. Need to replace ''hcan->Instance->'' to ''CAN1->'' in HAL_CAN_ConfigFilter function.

For stmf32f105

[valentin]

Posted on May 06, 2017 at 08:23

Hmm, I have to bring this thread back to life.

I'm just now looking at exactly that function (line 355) in stm32f2xx_hal_can.c (CubeMX 4.20.1, uptodate F2 firmware) and it seems as if every reference to the function parameter hcan has been replaced internally with CAN1. I noticed it thanks to a compiler warning.

@ST:

IF this is not a bug - it looks like it's not based on the thread history - please write a quick note in the comment above. Otherwise people might be tempted to just correct this issue.

OR even better: Remove the hcan parameter from the function! Yes, this is going to break successful compilation for some projects but only until they realize that the reference is not needed. That, together with an explanation in the comments would be the correct way of solving this situation.

Please, always remember that there are others working with that code and they have to understand what's going on.

Thanks!

[Paolo Chiantore]

Posted on July 20, 2017 at 10:46

Valentin,

I think hcan parameter is kept for compatibility with other micro of STM32 family.

For example in stm32f7xx_hal_can.c 'HAL_CAN_ConfigFilter' has to manage also CAN3 where defined (while replacing CAN2 instances with CAN1 as in your case).

[valentin]

Posted on July 20, 2017 at 22:57

I see where you're coming from and it makes sense. I do agree that there should be one function with the same interface for all of the different micro families.

Still, I would have expected something along the lines of:

if(hcan == CAN2) hcan = CAN1;

And then keep using hcan->...

With that approach it would be the same interface and even the same function for all types of micros, even the ones supporting CAN3 - which is a standalone master bxCAN again so I presume that it has its own filter banks.

A little more details in the comments in general go a long way with regards to intention and expected usage scenarios.