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

I've been referring to Production Mode. This is my main concern.

But, to answer your question, I get a hard fault in Engineering mode. 0693W000007CB6vQAG.png...this would also be nice to solve, as it renders debugging in engineering mode impossible.

@JCant.1​ ,

You should not call MX_OPENAMP_Init() in Engineering mode, because there is no other side - A7, there is only M4 running. You should place MX_OPENAMP_Init inside if(!IS_ENGINEERING_MODE).

Best regards,

Nenad

@NGajic​ , that makes sense. Though, CubeMX generates the code that calls it outside of the engineering mode check. I'll guess I can hack a wrapper around the auto-generated code.

JCant.1
Associate III

@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().

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

Indeed addition HAL_RCC_DeInit() was a bad idea since not supported in production mode. Sorry for that.

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.
Olivier GALLIEN
ST Employee

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

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.

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
Associate III

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

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