GDB PEMicro Interface Debugging

[davidskok]

I am working on a project with MK10DX256VLH7 processor in KDS using Processor Expert.

My application project uses FreeRTOS referenced in a separate static library project.  My app runs as expected in debugger however if I break after FreeRTOS started I cannot step without a reset occurring. I suspect the source of the problem might be a setting to Disable interrupts during stepping.  The Debug configuration I use in KDS is for GDB PEMicro Interface Debugging and the JTAG device I use is USB PEMicro Multilink Universal FX.  The GDB PEMicro Interface Debugging debug configuration setup in KDS has a fraction of the settings available in Codewarrior for PEMicro JTAG device.  The "disable interrupts during stepping" is one of the many settings that are not available.  Is it possible for me to make this setting through GDB commands that route to the PEMicro Multilink to do this.  Is there a different Eclipse plug-in to control PEMicro JTAG debugger?

Any help would be greatly appreciated,

Dave

[michaelcollins]

I can confirm that this problem also shows whether using the OSBDM or and actual Mutlilink Universal FX.

[davidskok]

Michael,

I have not resolved this problem yet.  I spent some time searching for processor settings that might be off and was not able to find anything outright incorrect.

I was able to debug without issues using CodeWarrior.  Problems started when I migrated to KDS and added FreeRTOS.  What stands out in my setup is

that I can break and step anytime prior to FreeRTOS starting.  Once it starts I cannot.  That is, when I restart after a break using single step or run, the

code resets.

D.

[BlackNight]

Hi David,

Can you verify that you do not have any breakpoints/watchpoints set (see Failed to Debug with GDB: Breakpoints or Expressions on non-existing Locations | MCU on Eclipse) as this was breaking debugging for me on GDB.

Which FreeRTOS port are you using? I ask because it could be that the stack frame confuses the GDB debugger.

I hope this helps,

Erich

[davidskok]

Erich,

Thank you for the tip.  I have seen this issue come up and also traced it to break points to code that is not present anymore.

Regarding FreeRTOS, I use version 8.0.1.  I use FreeRTOS as a separate static library project that I link against as opposed to processor expert managed FreeRTOS inside the application. I prefer to keep code functionality in separate libraries as much as possible so as to keep application code cleaner, to promote loose coupling and to make it easier to track dependencies.  I had experimented with processor expert plugin for FreeRTOS component while using CodeWarrior.  Breakpoints followed by stepping did work without issue when I used PE in Codewarrior.  I now use KDS which does not have FreeRTOS component although I am not sure if I need to add plugin separately or if I need to upgrade to newer v2.0.  I notice in your blog that you mention that FreeRTOS is now built into KDS.

To use FreeRTOS as a separate static library, I simply use processor expert in the KDS application project to set vector function names for SVC_Handler, PendSV_Handler and SysTick_Handler (FreeRTOS ISRs).  I set up systick timer 1ms and edit FreeRTOSConfig.h to match processor clock (72mhz) and tick time (1ms).  My application at this point is quite basic, there is no FreeRTOS calls in ISRs, only free running tasks that did what the application did without an RTOS plus a task to blink an LED.  LED blinks at the rate I expect given clock and tick settings.  The application works fine except for the breakpoint/step problem.

The FreeRTOS ISR code I use is the stock ISRs for GCC/CM3 that come with FreeRTOS.  I notice that FreeRTOS ISR code that CodeWarrior generated through PE component is more specialized for CM4.  Again, the processor I use is MK10DX256VLH7, it is not CM4F core.  The next thing I am going to look at is what is different in PE generated ISRs.

Any suggestions are welcome.

Thanks,

Dave

[BlackNight · Accepted solution]

Hi Dave,

The FreeRTOS Processor Expert plugin is part of the McuOnEclipse components available on SourceForge (McuOnEclipse Releases on SourceForge | MCU on Eclipse). If you have it installed in CodeWarrior, you need to install it in Kinetis Design Studio too, as it uses a different location where the files are installed (see CDE Hacking: Where is my stuff? A dissection… | MCU on Eclipse). FreeRTOS is not bundled automatically with KDS, but it is bundled with the Kinetis SDK.

Unrelated to your problem: The nice thing with the non-CodeWarrior (gdb) Eclipse (KDS) is that there is FreeRTOS debug plugin, see DIY Free Toolchain for Kinetis: Part 5 – FreeRTOS Eclipse Kernel Awareness with GDB | MCU on Eclipse

I'm using FreeRTOS with many projects (CodeWarrior, Kinetis Design Studio and stock Eclipse), and have not observed your problem. I don't believe it is related to the usage of libraries. But I noticed problems with J-Link and the RTOS stack or gdb stack trace.

What you can try is to limit the GDB back trace say to 20 in your debugger settings:

What else you can try (I use that for my Segger connections): Add the following to the FreeRTOSConfig.h

#define configTASK_RETURN_ADDRESS   0  /* return address of task is zero */

With this, the task stack will be terminated with zero (see port.c).

I hope this helps,

Erich

[davidskok]

Hi Erich,

Adding the line...

#define configTASK_RETURN_ADDRESS   0  /* return address of task is zero */

CORRECTED THE PROBLEM !!!!!!

I can't thank you enough :smileyhappy:

I took a look at port.c that is generated by PE in CodeWarrior and LR register on stack is hardcoded to 0 in pxPortInitialiseStack.  I have stock source of FreeRTOS 7.0.2 and found that it is hardcoded to 0 there also.  I was not aware of this setting in FreeRTOS that is apparently new in v8.x.x.

Thanks again!!

Dave

[BlackNight]

Yes, that setting came with v8.x.x. Actually it is a good setting as it will catch the case if you leave the task function. Otherwise it will jump into the wild.

But having that 'catch the exit of a task' function address somehow let gdb read from illegal addresses, and therefore causes problems.

Glad to hear that it solved the issue on your side.

Erich

[michaelcollins]

I tried each of those steps independently.  Setting the backtrace limit and having the HIS debug tools had no affect.  Configuring the return address seemed to fix the issue, in my case.  My setup was using the FreeRTOS port from the MCUonEclipse website on KDS 2.0 with no Kinetis SDK.

[BlackNight]

Hi Michael,

interesting, somehow I had the problem only with Segger J-Link. In any case, I already had that setting added to the McuOnEclipse FreeRTOS port. I plan to release it next week-end if time permits. Until then, add that

#define configTASK_RETURN_ADDRESS   0  /* return address of task is zero */

to the FreeRTOS configuration. And I will make that the above settings are the default.

Thanks,

Erich

[BlackNight]

PS: this is the setting I'm talking about:

Erich

[michaelcollins]

I am also having the same issue.  With KDS, FreeRTOS and P&E GDB.  I've tested it with KDS 1.1.1 and 2.0.0 and get the same results.  Interestingly, if I set the compiler optimizations for Size, I can use breakpoints normally, however it makes it real hard to see what is going on.  I found this because I wouldn't get the resets when debugging a Release build. Any help on this would be appreciated, since it is killing my productivity.  I am using a MK60FN1M0VLQ12 on a TWR-K60F120M board.

[BlackNight]

Hi Dave,

not sure what problem you are facing, but I'm debugging happily my applications with P&E GDB in KDS, and interrupts seem to be disabled during the step operation. So I can step through the application and RTOS code without problems? A reset should not happen, so it looks like you might have a watchdog running? Depending on the core, you can configure what should happen duriing debugging (e.g. if the timers continue to run or not).

Erich

[ZhangJennie]

Hello Dave.

I am afraid KDS doesn't have this feature.

if user needn't interrupt during debugging, I suggest disable interrupt register in code when debugging.

Hope this helps!

=====================================

this answer is for you, if it helps, please click on "Correct Answer" button. thanks!

Best Regards.

Zhang Jun