cancel
Showing results for 
Search instead for 
Did you mean: 

CAN BUS will not initialize on NUCLEO-F446RE but will initialize on NUCLEO-F446ZE. Why?

KiptonM
Lead

I am trying to get the CAN Bus to work.

I am using a NUCLEO-F446RE. It fails in the HAL_CAN_Init() routine. Which is code that is auto generated.

Someone suggested maybe the board is bad. Fortunately I had a NUCLEO-F446ZE (144 pin package board) and it did not stop at that point with no hardware hooked up.

I removed the hardware and the bare NUCLEO-F446RE still hung at the same place.

I determined my NUCLEO-F446RE board must be bad.

I ordered another NUCLEO-F446RE, and tested the bare board and it still hangs in the same place.

Is this a known issue?

Do I need to switch over to the NUCLEO-F446ZE if I want to use CAN?

1 ACCEPTED SOLUTION

Accepted Solutions
Imen GH
ST Employee

​Hello,

I suggest you debug, locate where the code hangs/stop to identify what is the problem and when it occurs.

I advise you to follow this discussion, maybe it’s the same problem

https://community.st.com/s/question/0D53W00000Sb2ZT/nucleof446re-can-bus-not-initializing

Imen

View solution in original post

5 REPLIES 5
Imen GH
ST Employee

Hello,

I recommend you to have a look to the working application available under STM32CubeF4 package which can help you as an implementation example:

STM32Cube_FW_F4_V1.26.1\Projects\STM32446E_EVAL\Examples\CAN\CAN_Loopback

Check if you have the same problem when running the CAN example    

So, you can compare your own project with the one available in the cube package.

Also you should check the pin configuration as the two boards do not have the same package.

Imen

KiptonM
Lead

I guess I did not make myself clear. I cannot even get to that point.

The IDE generates the initialization code.

 /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_USART2_UART_Init();
  MX_UART4_Init();
  MX_UART5_Init();
  MX_USART1_UART_Init();
  MX_USART6_UART_Init();
  MX_CAN1_Init();
  MX_TIM6_Init();
  MX_TIM13_Init();
  /* USER CODE BEGIN 2 */

It stops in the MX_CAN1_Init(); subroutine.

The lines

if (HAL_CAN_Init(&hcan1) != HAL_OK)
  {
    Error_Handler();
  }

cause it to go into the Error_Handler();

It happens with no HW hooked up in the NUCLEO_F446RE.

With the bare board of the NUCLEO_F446ZE it gets past that.

Why is there a difference between the boards?

I do not understand.

KiptonM
Lead

I tied PA11 and PA12 together and it gets past the initialization code. I Do not understand what is different between the two boards where one needs that and the other does not need that to initialize.

Imen GH
ST Employee

​Hello,

I suggest you debug, locate where the code hangs/stop to identify what is the problem and when it occurs.

I advise you to follow this discussion, maybe it’s the same problem

https://community.st.com/s/question/0D53W00000Sb2ZT/nucleof446re-can-bus-not-initializing

Imen

KiptonM
Lead

Thanks for the pointer.

It lead me to this: https://electronics.stackexchange.com/questions/353005/can-initialization-timeout-error-in-stm32f4/353101

I had the same problem when used silent loopback mode. The solution was to pull up RX pin so it could receive 11 recessive bits while changing a mode from "Initialization mode" to "Normal mode".

Edit:- I have also the same problem that during initialization the CAN was waiting for the ACK. but I found out that I set the Rx pin as GPIO_NOPULL mode and that makes problem because generally CAN bus is staying HIGH when there is no communication but it goes to LOW when the message is being sent via bus. The best solution is to configure the Rx and Tx pin as GPIO_PULLUP mode.

Why does the initialization not just pullup the CAN_RX? That would fix the problem for me and everyone else.