Debugging Giga with J-link- fails after one run, no changes

Official Hardware Mega GIGA R1 WiFi
1

So first, just for clarity, I have replies in a similar thread about a debugger problem I'm experiencing on a different machine; that issue remains unresolved. Unfortunately, I'm spending all my effort on debug tools, trying to get some (any) debugger going. Anyway, on to this particular problem:

In this case, I had the debugger running with segger tools, jlink probe, and IDE 2.3.2. It ran and break points worked, but when attempting to step over, it was stopping on blank lines, comments, sometimes stopping on the same blank line repeatedly, and jumping around to random places. I attempted to stop debugging, re-compile, and debug again. After that, the debugger won't start. Restarting stuff (IDE, Giga, PC) makes no difference:

Blockquote
Failed to launch undefined GDB Server: Error: spawn C:/Program Files/SEGGER/JLink_V796g/jLinkGDBServerCL.exe ENOENT

Here's the debug_custom.json:

[
  {
    "configId": "arduino:mbed_giga:giga:programmer=jlink",
    "server": "jlink",
    "servertype": "jlink",
    "device": "STM32H747XIH6",
    "interface": "swd",
    "serverPath": "C:/Program Files/SEGGER/JLink_V796g/jLinkGDBServerCL.exe",
    "serverpath": "C:/Program Files/SEGGER/JLink_V796g/jLinkGDBServerCL.exe"
  }
]

Any suggestions are welcome and appreciated!

2

The "Arduino Mbed OS Giga Boards" platform configures the compiler optimization level using the -Os flag:

The extensive optimization performed by the compiler with the -Os optimization setting is normally beneficial, but in during debugging it can be problematic when it results in a program binary that can differ so significantly from the source code that it renders the results of the debugger nonsensical.

For this reason, a system has been implemented to allow a platform to define two an alternative optimization configuration which can be selected by the user via the IDE's Sketch > Optimize for Debugging menu item.

Unfortunately that system has not yet been leveraged in the "Arduino Mbed OS Giga Boards" platform, so you always get the -Os optimization level regardless of the state of the Sketch > Optimize for Debugging menu item. This might be the explanation for the strange behavior you observed while debugging. There is a proposal to implement the Optimize for Debugging system in the "Arduino Mbed OS Giga Boards" platform here:

If you have a GitHub account, you can subscribe to that thread to get notifications of any new developments related to this subject:

screenshot of Subscribe button

Please verify that the file exists at this path:

C:/Program Files/SEGGER/JLink_V796g/jLinkGDBServerCL.exe

I did notice that the incorrect case of the "j" in jLinkGDBServerCL.exe. However, since Windows uses a case-insensitive filesystem, this shouldn't cause a problem so I think it was only a "red herring".

3

Ouchie - that hurts. This project is committed to the giga platform - the display is big enough to host the UI that's been worked out over the last year. Update: I'm able to run Ozone (stable), which unfortunately tells the same story: nonsensical / "impossible" code jumps, etc. Some of these are easily verified by watching variables, and the overall program behavior seems to match what the debugger is indicating. Does debugging - in it's current state of affairs - have an impact on execution? I'm concerned that the debug session is not the only thing in error, but some of the actual execution as well. I had indications of this (variables never declared, etc.) when i was debugging with Serial.print(), but couldn't confirm.

4

You can manually apply the patch from the unmerged pull request I mentioned in my previous reply if you like:

https://patch-diff.githubusercontent.com/raw/arduino/ArduinoCore-mbed/pull/853.patch

diff --git a/platform.txt b/platform.txt
index 0e7193624..58757b12d 100644
--- a/platform.txt
+++ b/platform.txt
@@ -16,15 +16,19 @@ compiler.warning_flags.default=
 compiler.warning_flags.more=-Wall
 compiler.warning_flags.all=-Wall -Wextra
 
+compiler.optimization_flags=
+compiler.optimization_flags.release=
+compiler.optimization_flags.debug=-Og
+
 compiler.path={build.compiler_path}
 compiler.c.cmd={build.crossprefix}gcc
-compiler.c.flags=-c {compiler.warning_flags} -g3 -nostdlib "@{compiler.mbed.defines}" "@{compiler.mbed.cflags}" {compiler.mbed.arch.define} -MMD -mcpu={build.mcu} {build.float-abi} {build.fpu}
+compiler.c.flags=-c {compiler.warning_flags} -g3 -nostdlib "@{compiler.mbed.defines}" "@{compiler.mbed.cflags}" {compiler.optimization_flags} {compiler.mbed.arch.define} -MMD -mcpu={build.mcu} {build.float-abi} {build.fpu}
 compiler.c.elf.cmd={build.crossprefix}g++
 compiler.c.elf.flags=-Wl,--gc-sections {compiler.warning_flags} -Wl,--as-needed
 compiler.S.cmd={build.crossprefix}g++
-compiler.S.flags=-c -x assembler-with-cpp -mcpu={build.mcu} {build.fpu}
+compiler.S.flags=-c -g -x assembler-with-cpp {compiler.optimization_flags} -mcpu={build.mcu} {build.fpu}
 compiler.cpp.cmd={build.crossprefix}g++
-compiler.cpp.flags=-c {compiler.warning_flags} -g3 -nostdlib "@{compiler.mbed.defines}" "@{compiler.mbed.cxxflags}" {compiler.mbed.arch.define} -MMD -mcpu={build.mcu} {build.float-abi} {build.fpu}
+compiler.cpp.flags=-c {compiler.warning_flags} -g3 -nostdlib "@{compiler.mbed.defines}" "@{compiler.mbed.cxxflags}" {compiler.optimization_flags} {compiler.mbed.arch.define} -MMD -mcpu={build.mcu} {build.float-abi} {build.fpu}
 compiler.ar.cmd={build.crossprefix}ar
 compiler.ar.flags=rcs
 compiler.objcopy.cmd=

I'll be happy to provide instructions for doing that if you want.

Only while debugging.

As long as the compiler is doing its job correctly, the runtime behavior of the optimized program binary should always accurately reflect the program code. It is only that the, in order to achieve high levels of optimization, the compiler sometimes performs some significant translations to machine code that precisely produces the intended runtime behavior, but in a manner that does not closely parallel the structure of the C++ code.

The structure of the machine code is irrelevant to us during normal program execution because the only thing that matters is that the machine is able to use it, but when debugging a human is indirectly interacting with that machine code while expecting it to parallel the structure of the project's C++ codebase. So it is only when debugging (or doing other work involving human interpretation of the machine code) that high optimization levels can cause confusion to the humans.

Bugs in the compiler that cause the runtime behavior of a binary to not match the source code do occur, but they are quite rare. Most often when people jump to the conclusion that the compiler is to blame for some unexpected behavior, it is later discovered that in fact the real cause was a bug in the code or a misunderstanding of how the code is intended to work.

If you encounter one of these "execution" problems you mention, you can share a minimal demonstration sketch that can be used to reproduce it here on the forum and the forum helpers will take a look.

5

Hi ptillisch,
That would be great, I'd love to have your your instructions - I'll follow them carefully. All help / hints / info. appreciated.

Agreed, it's hard to imagine an actual execution error. I didn't know how else to express it, given what seems to be happening (lines of code skipped outside of conditionals, etc. etc.). I hope this does end in a coding error of some kind; I can fix that.
As for optimization - the topic is above my pay grade so this may be a dumb question, but is it practical / desirable to have no optimization, thus, best fidelity to source code? I can't imagine that my application would be taxing for this board, and memory consumption is small. Just a thought. Lastly, I'm working on duplicating the problem with simplified code that I can post.
Thanks so much for all your help!

6

OK, here you go:

  1. If Arduino IDE is running, select File > Quit from the Arduino IDE menus.
    All Arduino IDE windows will close.
    ⓘ This is required because Arduino IDE does not recognize changes made to the platform configuration files while the IDE application is running.
  2. Click the following link to open the GitHub page for the patched platform.txt configuration file in your web browser:
    https://github.com/arduino/ArduinoCore-mbed/blob/3405968c87a578561673666c8b6e75d8e2fbf68f/platform.txt
  3. Click the button that looks like a downward pointing arrow ("Download raw file") on the file toolbar.
    Your web browser will start a file download.
  4. Replace the file at this path with the downloaded file:
    C:\Users\<username>\AppData\Local\Arduino15\packages\arduino\hardware\mbed_giga\4.1.3\platform.txt
    (Where <username> is your Windows username)
    :exclamation: If looking for it with your file manager or command line, note that the AppData folder is hidden by default. On Windows "File Explorer", you can make it visible by opening the "View" menu, then checking the box next to "☐ Hidden items".
  5. Start Arduino IDE.
  6. If it is not already, enable the Sketch > Optimize for Debugging menu item.
  7. Upload the sketch to your GIGA R1 WiFi board again
    ⓘ This is necessary to produce the binary with the debugger-friendly -Og compiler flag.
  8. Run a debugger session.

:exclamation: Make sure to disable the Sketch > Optimize for Debugging menu item when you aren't preparing a binary for a debugging session so that you can benefit from the higher -Os optimization level when the lower -Og level is not needed.

:exclamation: The patch will be lost if you update to a new version of the "Arduino Mbed OS GIGA Boards" platform using the Arduino IDE Boards Manager. Hopefully the pull request implementing the "Optimize for Debugging" feature will have been accepted by that time, but if not you can repeat the instructions above (adjusting the version number component of the path to the platform.txt file on your computer as appropriate) to replace the patch.

No. GCC is a professional quality compiler developed by incredibly talented and dedicated people. You should have faith in its ability to safely optimize your code unless you have clear evidence to the contrary.

GCC is used throughout the software and firmware development industry; not only in the Arduino ecosystem.

7

H ptillisch, Thanks so much - I applied the patch you mentioned above, all went well. The debugger still does some unexpected things, and I'm trying to find patterns. Now that the it runs (thank you again!!) I'm finally able to look at the root problem, which is touch screen behavior. I'm depending on the debugger to see what is happening; the serial.print method hasn't been effective this time. I'm working on a simplified version of the code that is practical to post.

As for the compiler question, I didn't mean to question the quality of GCC, or of anyone's work. I don't know how it all functions under the hood, so I'm just trying to understand and troubleshoot these issues as best I can.

Thanks again for helping with everything so far!

8

You are welcome. I'm glad you were able to apply the patch. Hopefully the use of the appropriate optimization level will at least improve the usefulness of the debugger even if it still isn't perfect.

Regards,
Per