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 @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

[NGajic]

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​

[JCant.1]

@Community member​ , has there been any progress on this? It's a rather large productivity detriment to have to reboot after every attempt at running the M4 FW. I'm also very concerned about the dependability of my end-device in the field, as I don't have a good way to do a full HW reboot after a field-upgrade.

If I put HAL_RCC_DeInit() before the HAL_Init(), which makes it the first line in main(), it appears that we never exit the HAL_RCC_DeInit().

[Olivier GALLIEN]

Hi @JCant.1​ ,

Sorry for inconvenience. I fully agree this problem need to be tackle.

I'm able to reproduce and I'm starting analyze of TIM Time Base in order to understand what's going wrong in case no reboot.

A ticket is open in our defect base and I will get help from expert.

Keep you posted soon.

Olivier

[Olivier GALLIEN]

Hi @JCant.1​ , @NGajic​ ,

I found the issue and a quick-and-dirty workaround .. but not yet the root cause.

I discover that on following debug session for some reason NVIC_ISER0 is not properly written, or maybe overwriten, to 0.

Means the TIM2IRQn on which is based the tick does not happen.

Adding  HAL_NVIC_EnableIRQ(TIM2_IRQn); just before  osKernelInitialize(); do the trick.

I'm no more stuck in HAL_Delay();

I resume investigation to understand what prevent to enable the IRQ at its nominal place in the code after restart of M4 firmware without hard reset.

So far, I didn't made any relation with MX_OpenAMP_Init() in this behavior.

Olivier

[JCant.1]

YAY!! OK, so I had HAL_Delay() calls prior to osKernelInitialize(), so I put the HAL_NVIC_EnableIRQ(TIM2_IRQn); just after the HAL_Init(). So, this is working for me now. I just did 7 back-to-back start/stop cycles of my M4 FW without the hang-up.

Thank you so much!

For what it's worth, other bugs in the HAL I've run into are due to the use of the SET_BIT macro where a simple assignment should be been used, thus previous values are retained when they should have been cleared. This fixed a bug in HAL_SYSCFG_AnalogSwitchConfig(), as described here.

[NGajic]

@JCant.1​ ,

2 months ago I managed to get HAL_Delay working 15 times, and then 16th time it hangs... It is upside in this post.

[NGajic]

@Community member​ ,

Unfortunately it is not working for me. I added HAL_NVIC_EnableIRQ(TIM2_IRQn); before osKernelInitialize(); and run this, but it worked only 4 to 5 times and then stopped. Diode LED7 on DK2 stopped toggling, showing that HAL_Delay hanged. After that I never managed to toggle diode with that same code.

[Olivier GALLIEN]

Hi @NGajic​ ,

Sorry to read this.

On my side on the pure OpenAMP_FreeRTOS_echo example, since I duplicate HAL_NVIC_EnableIRQ(TIM2_IRQn); just after the HAL_Init(), I'm unable to reproduce any issue after several terminate and relaunch operation ( at least 10 ).

Expert are still working to investigate root cause.

Olivier

[NGajic]

Hi @Community member​ ,

I'm not using debug mode. I'm running the firmware with echo start > /sys/class/remoteproc/remoteproc0/state. Here is my flow:

1. Build the binary (HAL_NVIC_EnableIRQ(TIM2_IRQn) is added after HAL_Init)
2. Transfer binary using SCP client (WinSCP)
3. Copy binary to /lib/firmware
4. echo OpenAMP_FreeRTOS_echo.elf > /sys/class/remoteproc/remoteproc0/firmware
5. echo start > /sys/class/remoteproc/remoteproc0/state
6. echo stop > /sys/class/remoteproc/remoteproc0/state

Do the 5. and 6. several times and the diode stop toggling. Code is OpenAMP_FreeRTOS_echo with added HAL_Delay(10) before if where diode is toggled (picture). Another question is how your TIM2_IRQHandler looks? Mine is on picture below.

[Olivier GALLIEN]

Hi @NGajic​ , @JCant.1​ ,

This is final explanation for the issue :

The issue is caused by one interrupt from the previous execution

that remains pending in the NVIC.

The new execution erroneously enable the TIM2 interrupts 'before'

setting in the handler:

/* Initialize TIM2 */

htim2.Instance = TIM2;

The pending interrupt immediately triggers the execution of the

IRQ handler TIM2_IRQHandler(), which finds 'htim2.Instance' not

initialized yet and, in response to this spurious interrupt,

disables the just enabled TIM2 interrupts.

This issue is more evident by using CubeIDE; to restart a new run

of the example, CubeIDE first halts the target core, then quits

from the debugger and restarts the firmware. When the core is

halted, TIM2 is still running, thus feeds in NVIC the interrupt

that will deterministically hang the next execution.

Patch attached.

Thanks for reporting and help to fix this issue !

Olivier