I am in the process of upgrading the toolchain and I've hit what I believe to be a bug in the Eclipse plugin or in the communication with the associated parts around it.
The device in question is: AT91SAM9G20
Old setup:
Kepler SR2 (Build id: 20140224-0627)
GNU ARM C/C++ Cross Compiler Support 1.8.1.201402180751
GNU Tools for ARM Embedded Processors 7.4.1.20130913
New setup:
Eclipse IDE 2019‑06 (Build id: 20190614-1200)
GNU MCU C/C++ ARM Cross Compiler 2.6.4.201901011632
GNU MCU C/C++ J-Link Debugging 4.3.4.201901011632
GNU Tools for ARM Embedded Processors 7.4.1.20130913
The old setup was using J-Link v4.90. The new one has been tested with v4.90, v6.22a and v6.50.
So the old setup has of course worked for years with no issues. However, after upgrading I no longer am able to set breakpoints in the C code. It will be shown as a breakpoint, but not set on the device (no check mark and no error indicated in the icon). If I press "Show breakpoints supported by selected target" in the breakpoints view, it disappears. They reappear if I deselect it. If I manually set breakpoints in the Debugger Console, it works. If I go in the disassembler view and set breakpoints on the assembly, it works too! If I step into/over/return it all works fine.
I believe this from the Debugger Console might be on to something:
GNU gdb (GNU Tools for ARM Embedded Processors) 7.4.1.20130913-cvs
Copyright (C) 2012 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=i586-mingw32 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Warning: the current language does not match this frame.
No source file named C:\\temp\\eclipse-test\\FirstProject\\src\\main.c
The breakpoint I'm trying to set is indeed in main.c, and if one ignores the double \ the path is correct.
For the record, this works fine on Linux with identical versions of the items listed above.
This leads me to believe there is something Windows specific about this, possibly related to paths.
Are there any way for me to get a more verbose output to know what GDB is actually started with and how the breakpoint is sent to GDB? It would be nice to rule out some kind of issue with the path provided.
As for the warning: I have tried "show language" in the debugger console, and that gives back
The current source language is "auto; currently c".
That is admittedly a bit contradictory to the warning it provides earlier. It also makes little sense since when I try to set additional breakpoints, it will spit out an additional
No source file named C:\\temp\\eclipse-test\\FirstProject\\src\\main.c.
So it seems to be is some issue with resolving the path when the breakpoint is set from source, but I'm not able to pin it down further than this at the moment.
I am in the process of upgrading the toolchain and I've hit what I believe to be a bug in the Eclipse plugin or in the communication with the associated parts around it.
The device in question is: AT91SAM9G20
Old setup: Kepler SR2 (Build id: 20140224-0627) GNU ARM C/C++ Cross Compiler Support 1.8.1.201402180751 GNU Tools for ARM Embedded Processors 7.4.1.20130913
New setup: Eclipse IDE 2019‑06 (Build id: 20190614-1200) GNU MCU C/C++ ARM Cross Compiler 2.6.4.201901011632 GNU MCU C/C++ J-Link Debugging 4.3.4.201901011632 GNU Tools for ARM Embedded Processors 7.4.1.20130913
The old setup was using J-Link v4.90. The new one has been tested with v4.90, v6.22a and v6.50.
So the old setup has of course worked for years with no issues. However, after upgrading I no longer am able to set breakpoints in the C code. It will be shown as a breakpoint, but not set on the device (no check mark and no error indicated in the icon). If I press "Show breakpoints supported by selected target" in the breakpoints view, it disappears. They reappear if I deselect it. If I manually set breakpoints in the Debugger Console, it works. If I go in the disassembler view and set breakpoints on the assembly, it works too! If I step into/over/return it all works fine.
I believe this from the Debugger Console might be on to something:
The breakpoint I'm trying to set is indeed in main.c, and if one ignores the double \ the path is correct. For the record, this works fine on Linux with identical versions of the items listed above. This leads me to believe there is something Windows specific about this, possibly related to paths.
Are there any way for me to get a more verbose output to know what GDB is actually started with and how the breakpoint is sent to GDB? It would be nice to rule out some kind of issue with the path provided. As for the warning: I have tried "show language" in the debugger console, and that gives back
That is admittedly a bit contradictory to the warning it provides earlier. It also makes little sense since when I try to set additional breakpoints, it will spit out an additional
So it seems to be is some issue with resolving the path when the breakpoint is set from source, but I'm not able to pin it down further than this at the moment.