Gets stuck in OS_Task when not using a debugger

[CamMcB]

My program runs as it should in debug mode switching between the OS_Tasks when released from the current task. However, when running the code without a debugger the program gets stuck in one task, resulting in the system crashing as the watchdog is no longer refreshed. 

I would be grateful for any suggestions on why the program is running differently in the 2 instances? and if there are certain settings I may not be considering when going from using the debugger to not. 

Thanks

[CamMcB]

Hi all thanks for the responses. I've been trying to work through some of the suggestions and I found that when I attach the debugger to the program when its already running it's not executing OSA_TimeDelay() correctly. As in OSA_TimeDelay() is not releasing the processor to be used in another task. I think it might be due to some aspects of the clock not being initialised correctly but I can't find what it is. Any suggestions would be appreciated thank you. 

[ErichStyger]

>> "the program gets stuck in one task, resulting in the system crashing as the watchdog is no longer refreshed. "

Maybe it is about the word 'crashing', but if the watchdog triggers it should do a proper reset/restart of the system and not crash.

What I would do is: in the watchdog routine, keep a counter to detect when the watchdog is about to expire. If it is about to expire, enter an endless loop and keep the watchdog happy. Then attach with the debugger (see https://mcuoneclipse.com/2021/04/25/attach-with-the-debugger-to-a-running-target/ ) and you can see what is wrong in your system.

Otherwise: I hope you are using FreeRTOS, then you can use SEGGER SystemView (see https://mcuoneclipse.com/2015/11/16/segger-systemview-realtime-analysis-and-visualization-for-freert... set it up for post-mortem analysis, let it run into the problem, then attach with the debugger and see what happened.

I hope this helps,

Erich

[ErichStyger]

are you using any kind of printf() or similar, especially if using semihosting? If yes, then your hard_fault handler might not properly deal with it. See https://github.com/ErichStyger/McuOnEclipseLibrary/blob/master/lib/src/McuHardFault.c for a handler which deals with semihosting printf() even in absence of a debugger.

Are you using a Cortex-M4 or M4? If so, then you might not have initialized the ARM DWT hardware from your application, as it is done by the debugger otherwise. See https://mcuoneclipse.com/2017/01/30/cycle-counting-on-arm-cortex-m-with-dwt/ . See https://github.com/ErichStyger/McuOnEclipseLibrary/blob/master/lib/src/McuArmTools.c how you could initialize it.

I hope this helps,

Erich

[danielchen]

Hi @CamMcB :

I would suggest you check the warnings from the compiler.

Debug builds set uninitialized local variables to a special value, 0 for instance, to facilitate debug tracking. while for release builds, these variables maybe have the random contents.   This maybe results in some unpredicted behavior.

Regards

Daniel