HAL Tick does not get incremented on second debug session after reset (FreeRTOS)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-07-28 05:59 AM
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
Solved! Go to Solution.
- Labels:
-
FreeRTOS
-
ST-Boards
-
STM32CubeIDE
-
STM32MP15 Lines
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-23 04:59 AM
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
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-23 06:04 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-01-19 06:12 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-01-20 12:38 AM
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
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-01-20 02:16 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-01-20 06:26 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-01-20 06:42 AM
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
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-01-20 01:33 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-01-21 01:58 AM
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
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-01-21 02:07 AM
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​
