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.
2021-02-01 01:46 AM
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
2020-07-29 12:19 AM
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
2020-07-29 03:30 AM
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
2020-07-29 03:48 AM
Hi @NGajic
Thanks a lot for this trial. This help.
Starting to reproduce for analyze at my end.
Olivier
2020-07-30 08:42 AM
Hi @NGajic ,
I confirm the issue
Dedicated team will informed and asked for correction.
I'll keep you informed.
Milan
2020-08-18 02:38 AM
hi
any update on this, or have some hot fix to resolve this problem
pls share.
thanks.
2020-09-01 01:34 AM
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
2020-11-19 12:44 AM
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
2020-11-19 12:55 AM
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
2020-11-23 03:39 AM
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