cancel
Showing results for 
Search instead for 
Did you mean: 

HAL Tick does not get incremented on second debug session after reset (FreeRTOS)

NGajic
Associate III

I'm working on project that is including ADC, timers and virtual UART. I'm working on STM32MP157C-DK2 board. So I started from example OpenAMP_FreeRTOS_echo from CubeMP1 software package v1.2.0. I'm using CubeIDE v1.4.0. When I reboot STM32MP1 and debug for the first time after reboot, and place breakpoint into HAL_TIM_PeriodElapsedCallback function in which HAL_IncTick is called, everything is fine and the program is stopping here. Problem is that when I debug for the second time (and software on M4 is stopped before 2nd debug) program is not stopping on breakpoint and the HAL tick is not getting incremented. The code is not being modified, it is the same as in examples. On boot I choose the device tree number 3 which is used for M4 examples. Question is why is this happening and do I need to reboot the board every time I want to debug?

Thanks in advance,

Nenad

35 REPLIES 35

Hi @NGajic​ ,

Thanks for this detailed analyze. I noticed the same on my side.

Reason is probably because when re-starting second debug session only a M4 core reset occurs. Peripheral are not reseted.

This might lead to wrong initialization of TIM2 as tick timebase.

Workaround might be to insert proper deinit function at the right place. Still investigating.

Will let you know.

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Thanks @Community member​ ,

I tried in run mode to read NVIC ISER (Interrupt Set Enable Register) on top of main() and then if TIM2_IRQn is active to do HAL_NVIC_DisableIRQ(TIM2_IRQn); but this didn't solve problem.

Best regards,

Nenad

JCant.1
Associate III

I'm seeing this as well. @Community member​, has there been any progress or another suggested workaround? I tried calling HAL_TIM_Base_DeInit() prior to HAL_Init(), to no avail.

Best regards,

Jon

Hi @JCant.1​ , @NGajic​ ,

Suggestion of adding HAL_RCC_DeInit() prior to HAL_Init() looks to unlock some customer facing similar issue.

Could you make a try ?

Thx

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
NGajic
Associate III

I used same example as explained above with HAL_Delay(10) just before LED7 toggle and added HAL_RCC_DeInit before HAL_Init. It is not working. Diode is not toggling at all.

Nenad

Thank you for getting back to me. I tried HAL_RCC_DeInit(), as well as HAL_DeInit(), HAL_MspDeInit() and HAL_TIM_Base_DeInit(&htim2). None of these did the trick. It seems that I can sometimes get 2 or 3 subsequent runs to work, but eventually TIM2 stops ticking and I end up hanging within the first HAL_Delay() call in my code.

Olivier GALLIEN
ST Employee

Thanks for your trials and apology for inconvenience.

If you get 2 or 3 trials working maybe it actually did the tricks .. but you are facing another issue ?

Will need reproduction and further investigation at our end.

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

I sometimes get 2-3 trials working with or without the DeInit calls, so they aren't helping. If I comment out the MX_OPENAMP_Init(RPMSG_REMOTE, NULL) call, I never have the issue where HAL_Delay() hangs. It seems that initializing OpenAMP is doing something that impacts TIM2 such that uwTick never updates. But I can't see how.

Olivier GALLIEN
ST Employee

Hi @JCant.1​ , @NGajic​ 

Can you please clarify if your latest status was using production or engineering mode ?

Did you notice any difference in one mode or another ?

Thx

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Hi @Community member,

There's no issue in Engineering mode. There is issue in Production mode where A7 control some system resources. I tested OpenAMP_FreeRTOS_echo in production mode, off course.

Nenad​