2018-12-29 11:04 AM
Mcu: STM32F446RET6
STM32CubeMX 5.0.0 (STM32Cube V1.0)
So, yeah i figured out that if i use LL_RCC_DRIVER and then any periephal which only does have HAL_driver implemented by ST, it will get stuck in infinity loop in the corresponding init function.
ie.
if (HAL_CAN_Init(&hcan1) != HAL_OK) // <<- permanently stuck
{
Error_Handler();
}
and the actual infinity loop is below.
while ((hcan->Instance->MSR & CAN_MSR_SLAK) != RESET) // <-- Always true
{
if ((HAL_GetTick() - tickstart) > CAN_TIMEOUT_VALUE) // <-- never true
{
/* Update error code */
hcan->ErrorCode |= HAL_CAN_ERROR_TIMEOUT;
/* Change CAN state */
hcan->State = HAL_CAN_STATE_ERROR;
return HAL_ERROR;
}
}
Now i ask, why i'm able to select LL and HAL driver mixture from cubeMX if it does not work anyway, using HAL_RCC driver and this proplem is gone, but that is not a fix.
Second, MX_CAN2_Init() always results into HAL_ERROR?
2018-12-29 12:03 PM
Some other fresh thread talk about Systick not working well with latest CubeMX.
Maybe there is a link here?
HAL_GetTick() relies on Systick.
If this one is not working, yes, the timeout may not happen as time is "frozen"?
2018-12-29 12:39 PM
I'm pretty sure it did return 0 always(need to check later again to be sure), which would make the timeout not work. But that is only if I try to use low level driver for the RCC, using HAL driver for RCC and it does work.(HAL_GetTick() does return values)
Well or atleast the init works, can't get the can loopback work properly, but that is issue for another topic.
2018-12-29 01:51 PM
The SysTick_Handler needs to minimally call HAL_IncTick() for the counter to advance. The SystTick also needs to have sufficient preempt priority to cut through other callbacks or interrupts that have dependency.