Breakpoing in ISR crashes NXP version of GDB

[definium]

Hi there,

I am having debugging issues with lpcxpresso version 8.2.0. It may affect version 8.1.4 as well.

The issue is with an LPCOpen based project on the LPC11U68 although I have noticed similar problems on an LPC1549 project.

The issue is simply that setting breakpoints in ISR's causes GDB to die. Here is the GDB console output.

GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160210-cvs-LPCXpresso003

Copyright (C) 2015 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "--host=i686-linux-gnu --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word".

0x1fff00a0 in ?? ()

Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, main () at ../example/src/freertos_blinky.c:77

77        prvSetupHardware();

Program received signal SIGINT, Interrupt.

0x0000031c in vApplicationIdleHook () at ../freertos/src/FreeRTOSCommonHooks.c:76

76    }

Breakpoint 2, TIMER32_0_IRQHandler () at ../example/src/timer.c:38

38        if (Chip_TIMER_MatchPending(LPC_TIMER32_0, 0)) {

/media/workdisk/build/manual-builds/gcc-arm-none-eabi-5_3-2016q1-20160330/src/gdb/gdb/regcache.c:176: internal-error: register_size: Assertion `regnum >= 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_num_pseudo_regs (gdbarch))' failed.

A problem internal to GDB has been detected,

further debugging may prove unreliable.

Quit this debugging session? (y or n) [answered Y; input not from terminal]

This is a bug, please report it./media/workdisk/build/manual-builds/gcc-arm-none-eabi-5_3-2016q1-20160330/src/gdb/gdb/regcache.c:176: internal-error: register_size: Assertion `regnum >= 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_num_pseudo_regs (gdbarch))' failed.

A problem internal to GDB has been detected,

further debugging may prove unreliable.

Note that the preceding GDB output was produced while debugging the slightly modified freertos_blinky example project. I removed two of the led blink tasks and added a very simple timer ISR plus init code.

Even without the timer ISR,  just setting a breakpoint in the freertos systick ISR produces the same error followed by a terminated debug session.

I experimented a bit and made the following observations:

1. A project that does not use freertos does not exhibit the problem
2. Modifying the debug configuration to use the latest arm-none-eabi-gdb from launchpad fixes things

Is this a known bug with NXP's version of GDB?

Is there something I am missing or was testing debugging with freertos not in the test plan?

I have attached the project that I was using the figure out what was going on. Hope it helps.

I would appreciate some feedback on this issue as it has cost me several days in eliminating

possible hardware causes.

Regards,

Mike

Original Attachment has been moved to: gdb_freertos_test.tar.gz

[lpcxpresso_supp]

For your reference - LPCXpresso IDE v8.2.2 has just been released. This ships with the ARM Launchpad GCC5 update 2 release, including the updated GDB.

Regards,

LPCXpresso Support

[lpcxpresso_supp]

From our investigations It appears that further changes were made in the GDB sources for ARM's GCC5 update2 release after the patch that we applied to the update1 sources for inclusion in LPCXpresso IDE v8.2.0. The patch we applied fixed some issues related to debugging through interrupt service routines, but it appears it was not as complete solution as we had thought and is triggering issues with FreeRTOS ISR debugging as you report.

We will be switching to GCC5 update2 in our next tools release. But for the present, for debugging FreeRTOS based applications, I suggest that you manually patch your LPCXpresso IDE v8.2.0 install (in directory <installdir>\lpcxpresso\tools\bin) with the GDB executable (arm-none-eabi-gdb.exe) from the GCC5 update 2 release (downloadable from : GNU ARM Embedded Toolchain in Launchpad ).

With regards to the faults register message you are seeing, we haven't seen that one. Does debugging continue OK after you see this? And is that just with the LPCXpresso IDE v8.2.0 supplied GDB, or the update2 one as well? And are the hard faults being triggered in ISRs or just in general code?

Regards,

LPCXpresso Support

[definium]

Thanks for the response. I was just customizing the debug configuration for each project but copying the latest GDB in to the lpcxpresso tools/bnin folder removes the need for that.

As for the faults register issue, we will need to reproduce it to get more information. I cannot remember if the fault was in an ISR or not. Won't be too difficult to do that. I'll get back to you on that.

[lpcxpresso_supp]

Thanks for your report. We will investigate.

But the GDB build we supply in LPCXpresso IDE v8.2.0 is the version from the ARM GCC5 update1, with a (public) patch added for an issue with ISRs (which ARM were going to incorporate into their update2 release). Unfortunately update2 came out too late in our release cycle for us to pick up directly,

Regards,

LPCXpresso Support

[definium]

Hi there, I

understood regarding the changes to GDB. Nonetheless the version that comes with 8.2.0 fails whereas the latest from launchpad greatly improves things. The code seems not to be at fault as the problem can be reproduced by setting a

breakpoint in the systick handler of a freertos LPCOpen example.

Now this could simply be an environmental issue I guess but we see this happen on four different development systems, three linux and one osx. And we see it with LPC11U68, LPC1549 and LPC4337 projects so far. All are using freertos.

Added to that, on the LPC011U68 we keep running getting a dialog stating that the "faults" register is unknown when trying to diagnose hard faults. Probably related to the same issue above.

Have you tried setting a breakpoint in an ISR of the project I sent or in the systick handler of one of the LPCOpen freertos examples.

I am having a hard time understanding how the combination of freertos and debugging ISR's could cause this to happen but it seems consistent.

Regards,

Mike