2021-04-22 08:24 AM
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?
Solved! Go to Solution.
2021-04-26 05:34 AM
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
2021-04-23 05:48 AM
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
2021-04-23 11:43 AM
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.
2021-04-23 11:54 AM
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.
2021-04-26 05:34 AM
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
2021-04-26 07:51 AM
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.