Breakpoints Ignored in Tasks in FreeRTOS

[lpcware]

Content originally posted in LPCWare by toddatm on Fri Dec 23 17:26:00 MST 2011
I've got the LPCXpresso with FreeRTOS and built the first example, which creates 2 simple tasks. I built everything as it was set up and downloaded and ran with the debugger and the code runs. However, when I set breakpoints in the tasks the debugger doesn't halt at the breakpoints.

Tried searching the forum for a similar issue. Would seem to be a common issue if something isn't configured correctly since I haven't changed any out-of-the-box configuration settings, but I didn't see anything in the manuals from FreeRTOS or LPCXpresso or in the forums about this behavior.

Is there some magic to debugging a task? Why would my breakpoints be ignored?

If I set the breakpoints before I started the code the first time, one of them got executed, but after a "Resume", no more.

[lpcware]

Content originally posted in LPCWare by toddatm on Sun Jan 08 12:09:53 MST 2012

---

Quote: Rob65
Great, nice to hear.
Still a bit strange, the project wizard always using -O0 for the Debug build.
Guess Merlin had an off-day ;)

---

Or his helper, Todd, was messing about the shop while he was napping.

---

Quote:

You might still see strange things during single stepping.
Single stepping only stops on the next instruction in your current function/task.

---

This is very good information. Thanks.

So that probably means you get an interrupt storm when you step if you have several timer and other interrupts going. Not ideal. Is that a function of how gdb works? If I purchase a jtag debugger like Lauterbach, Arium, Signum, etc., would I expect that timer interrupts might be handled on schedule while waiting between steps? Or that it might be configurable on these other debuggers? They don't exactly advertise this information in their marketing literature!

Thanks for the help.

Todd

[lpcware]

Content originally posted in LPCWare by Rob65 on Sat Jan 07 01:09:23 MST 2012

---

Quote: toddatm

Backtracking to figure out the exact culprit, I found that using -O1 on my main.c causes the breakpoints not to work, -O0 and the breakpoints work.

---

Great, nice to hear.
I did not have that much time yesterday so I was quite happy to read that you already fixed it yourself.
Still a bit strange, the project wizard always using -O0 for the Debug build.
Guess Merlin had an off-day ;)

You might still see strange things during single stepping.
Single stepping only stops on the next instruction in your current function/task. So if a task switch (in a pr-emptive system) occurs or if an interrupt get fired this will be handled during the execution of that one instruction you step over.

As an example; I have an application containing an LCD backlight with a timeout. I am using a timer that I reset at every key press and as soon as the timer expires it will call a function to switch off the backlight.
While single stepping I suddenly see that the backllight is switched off.

The nice thing is that this does mean that other tasks and interrupts are being server while single stepping. But only when you press the Step over/into/return buttons - when the debugger tells you the system is paused, no interrupts are executed.

Regards,
[INDENT]Rob
[/INDENT]

[lpcware]

Content originally posted in LPCWare by toddatm on Thu Jan 05 20:19:15 MST 2012
I have it working now.

All I did was the following:
set both libraries and the main project to all have the same compile options:
-g3
-O0 (some had 1 before)
add -ffunction-sections on all 3 (this was missing on the FreeRTOS_Library)
I put --gc-sections on the linker back on.

Cleaned all and rebuilt everything, and now it's working. Go figure.

Backtracking to figure out the exact culprit, I found that using -O1 on my main.c causes the breakpoints not to work, -O0 and the breakpoints work.

[lpcware]

Content originally posted in LPCWare by toddatm on Thu Jan 05 17:29:17 MST 2012
I did try looking at the dissasembly and setting the breakpoint there at the absolute address. The breakpoint address matched the address of the function symbols in the link map. It breaks once at each breakpoint if I set them before everything starts running, and then never again. If I start everything first, then suspend, then set the breakpoints and run, the code never breaks.

I noticed a note in the gcc man page about possible debugging problems with both -g option and -ffunction-sections options being used together. I tried removing -gc-sections and reducing or eliminating the -g option (-g3 to -g to no -g) and also tried removing the -ffunction-sections. These not only didn't help, they seemed to introduce other problems debugging (the debugger said it couldn't find the source for the functions when it stopped, for example).

[lpcware]

Content originally posted in LPCWare by toddatm on Thu Jan 05 14:14:03 MST 2012
I'll attach a zip file with the exported projects. Thanks!

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Jan 05 13:20:41 MST 2012
If there is some way to post your workspace (expost all projects as .zip archive) then I could see if I find something funny tomorrow morning (about 10 hours from now).

Rob

[lpcware]

Content originally posted in LPCWare by toddatm on Thu Jan 05 13:12:08 MST 2012
Thanks. I tried removing the --gc-sections, but it didn't help. I'm putting the output of my build here in case you or anyone else spots something funny.

**** Build of configuration Debug for project Example01 ****
make all
Building file: ../cr_startup_lpc17.c
Invoking: MCU C Compiler
arm-none-eabi-gcc -DDEBUG -D__USE_CMSIS=CMSISv1p30_LPC17xx -D__CODE_RED -D__REDLIB__ -I"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\FreeRTOS_Library\demo_code" -I"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\CMSISv1p30_LPC17xx\inc" -I"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\FreeRTOS_Library\include" -I"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\FreeRTOS_Library\portable" -O1 -g3 -fsigned-char -c -fmessage-length=0 -fno-builtin -ffunction-sections -mcpu=cortex-m3 -mthumb -MMD -MP -MF"cr_startup_lpc17.d" -MT"cr_startup_lpc17.d" -o"cr_startup_lpc17.o" "../cr_startup_lpc17.c"
Finished building: ../cr_startup_lpc17.c

Building file: ../main.c
Invoking: MCU C Compiler
arm-none-eabi-gcc -DDEBUG -D__USE_CMSIS=CMSISv1p30_LPC17xx -D__CODE_RED -D__REDLIB__ -I"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\FreeRTOS_Library\demo_code" -I"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\CMSISv1p30_LPC17xx\inc" -I"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\FreeRTOS_Library\include" -I"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\FreeRTOS_Library\portable" -O1 -g3 -fsigned-char -c -fmessage-length=0 -fno-builtin -ffunction-sections -mcpu=cortex-m3 -mthumb -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.c"
Finished building: ../main.c

Building target: Example01.axf
Invoking: MCU Linker
arm-none-eabi-gcc -nostdlib -L"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\CMSISv1p30_LPC17xx\Debug" -L"C:\Users\toddt.MARVELL\Documents\LPCXpresso_4.0.5_123\workspace\FreeRTOS_Library\Debug" -Xlinker -Map=Example01.map -mcpu=cortex-m3 -mthumb -T "example01_Debug.ld" -o"Example01.axf"  ./cr_startup_lpc17.o ./main.o   -lCMSISv1p30_LPC17xx -lFreeRTOS_Library
Finished building target: Example01.axf

make --no-print-directory post-build
Performing post-build steps
arm-none-eabi-size Example01.axf; # arm-none-eabi-objcopy -O ihex Example01.axf Example01.hex ;
   text    data     bss     dec     hex filename
  20672      12   10908   31592    7b68 Example01.axf

[lpcware]

Content originally posted in LPCWare by Rob65 on Thu Jan 05 12:55:41 MST 2012
Could you try to remove the --gc-section (or similar, I forgot the exact name and don't have the LPCxpresso tools with me) in the settings of the linker.

This option may mess up your debug information which results in strange behaviour during single stepping. The debugger  misalligns the addressez and the line numbs in your source file.

As a result, breakpoints may end up at a different location in memory as where you think they are (and as such they might never be hit...)

Regards,

Rob

[lpcware]

Content originally posted in LPCWare by toddatm on Thu Jan 05 12:25:58 MST 2012
The way I acquired LPCXpresso and my NXP board was through the FreeRTOS website as a demo environment for FreeRTOS. So I've compiled the first example, 2 simple tasks, and the code executes fine. They just print out alternating messages.

However, in LPCXpresso I set a break point in both tasks, and would expect to alternately hit the breakpoints. The breakpoints are ignored! My original post seemed to perhaps not be clear.

Has anyone on this forum seen a problem setting breakpoints in tasks in FreeRTOS? Is there some setting for the debugger that I don't have set right?

Here's the code, just to be a bit more clear:

void vTask1( void *pvParameters )
{
const char *pcTaskName = "Task 1 is running\n";
volatile unsigned long ul;
/* As per most tasks, this task is implemented in an infinite loop. */
for( ;; )
{
  /* Print out the name of this task. */
  vPrintString( pcTaskName );
  /* Delay for a period. */
  for( ul = 0; ul < mainDELAY_LOOP_COUNT; ul++ )
  {
   /* This loop is just a very crude delay implementation.  There is
   nothing to do in here.  Later exercises will replace this crude
   loop with a proper delay/sleep function. */
  }
}
}
/*-----------------------------------------------------------*/
void vTask2( void *pvParameters )
{
const char *pcTaskName = "Task 2 is running\n";
volatile unsigned long ul;
/* As per most tasks, this task is implemented in an infinite loop. */
for( ;; )
{
  /* Print out the name of this task. */
  vPrintString( pcTaskName );
  /* Delay for a period. */
  for( ul = 0; ul < mainDELAY_LOOP_COUNT; ul++ )
  {
   /* This loop is just a very crude delay implementation.  There is
   nothing to do in here.  Later exercises will replace this crude
   loop with a proper delay/sleep function. */
  }
}
}

If I set breakpoints at the vPrintStrings or the for loops, doesn't matter where as long as it's inside the outer for loop, I'd expect to alternately hit my breakpoints. The breakpoints show up in the debugger, and when I run the code, the printouts happen in the console window, but the debugger does not stop at the break points.

I'm not really sure where to start debugging this. I'm somewhat new to this arm cortex m3. I would expect the debugger would setup hardware breakpoints (since the code is flashed) for the two breakpoints when I insert them.

Any help would be appreciated!

[lpcware]

Content originally posted in LPCWare by toddatm on Sat Dec 24 13:18:46 MST 2011
I can tell the code is executing past the breakpoints I set. There are prints in the main loop and they are printing. The delays are small, hard for loop delays.

This is the Example01 in the FreeRTOS distribution. 2 simple tasks which have a while forever loop with a hard delay loop and all they do in the loop is print the name of the task.

The debugger shows the breakpoints being set, but when I resume the debugger, the breakpoints never break.

I'm wondering if there's some special setting in the debugger, or it's something to do with using soft vs hard breakpoints when debugging tasks in FreeRTOS? Or something to do with interrupt context versus non? (I believe everything FreeRTOS everything is running in priveleged mode.)

[lpcware]

Content originally posted in LPCWare by OXO on Sat Dec 24 04:42:42 MST 2011
Probably the tasks are not restarting after your breakpoints again.

For example, if you have them timed, then the time for the next task initiation has already passed when you manually resume after the bp. The task will eventually run, but only when the timer has rolled over.