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

[NGajic]

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

[Olivier GALLIEN]

Hi @NGajic​ 

>> I'm using CubeIDE v1.4.0

This is a very last version release 2 days ago. Did you work with CubeIDE 1.3 version previously with or without same behavior ?

Thanks

Olivier

[NGajic]

Hi @Community member​ 

I downloaded CubeIDE v1.3 and it is the same situation. HAL Tick is incremented in 1st debug session and then in 2nd session it is not incremented. I clicked on pause to see if program is in some infinite loop, but that is not the case.

Nenad

[Olivier GALLIEN]

Hi @NGajic

Thanks a lot for this trial. This help.

Starting to reproduce for analyze at my end.

Olivier

[mleo]

Hi @NGajic​ ,

I confirm the issue

Dedicated team will informed and asked for correction.

I'll keep you informed.

Milan

[cboon.1]

hi

any update on this, or have some hot fix to resolve this problem

pls share.

thanks.

[NGajic]

Hi @mleo​ ,

Is there any update on this problem, is there a solution? I'm curious because now I have to make a decision to go with or without FreeRTOS, and definitely FreeRTOS is the best thing for a job that I have to solve.

Nenad

[Olivier GALLIEN]

Hi @NGajic​ ,

Sorry for late reply. Actually @mleo left the company that's why we missed your september update.

If not mandatory to you to stick on ecocystem V1.2, could you give a try with the freshly released V2.1 and latest STM32CubeIDE1.5 ?

We will proceed also to some verification our side.

Thanks,

Olivier

[NGajic]

Hi @Community member​ ,

Thanks for the answer, I didn't try ecosystem 2.1 and latest IDE... I hope I will try this soon, because I'm busy right now. I will inform you if I get this done.

Thanks,

Nenad

[NGajic]

Hi @Community member​ ,

I downloaded Starter package of ecosystem 2.1 and latest CubeIDE v1.5.0. and the latest CubeMP1 firmware package v1.3.0. Unfortunately project OpenAMP_FreeRTOS_echo is behaving same like before, HAL tick is not incremented on second debug session. Everybody who uses this project as is do not see the problem because it is doing everything it have to do (echoing virtual uart messages), but if you want to add some periferal that uses HAL tick it is not going to work. I think that maybe problem is only in debug mode, so I tried to run example using remoteproc on Linux using start and stop. For purpose to see if everything is working I added HAL_Delay in task that is toggling LED7 (HAL_Delay before toggling diode). If diode is toggling HAL_Tick is incremented, if not it isn't. So firmware worked for about 15 times, and then when I stopped and started firmware again diode wasn't toggling i.e. HAL tick increment stopped. Then I restarted board and tried again and this time it worked only first time and then on second run HAL tick increment stopped. So it is not working in run mode also.

Best regards,

Nenad

[Olivier GALLIEN]

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

[NGajic]

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]

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

[Olivier GALLIEN]

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

[JCant.1]

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.

[NGajic]

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

[Olivier GALLIEN]

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

[JCant.1]

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.