NRFConnect, debug the special example named 'NRFX'

[ThomVisGdb04]

targeting the NRF9160 DK (‘Non-Secure’ nrf9160ns) per NCS 1.5.1
with VisualGDB (build 4132 from this forum, due latest VS 16.10 breaking) and the VisualGDB own arm-GCC 9.3.1 toolchain. Both the ncs folder and my project are on same drive.

I tried to follow tutorial
https://visualgdb.com/tutorials/arm/nrfconnect/nrf9160/

but in your NRFConnect wizzard, I’m selecting the offered, SPECIAL example named ‘NRFX’ from ncs zephyr folder
v1.5.1\zephyr\samples\boards\nrf\nrfx
demonstrating the GPIOTE and DPPI/PPI using nrfx API directly (without a zephyr device).

First, this example runs OK with the Nordic provided SES IDE!
(NOTE: it has a source bug with the DPPI-out LED not toggling, but thats another story!)

-BUT-
debugging with VisualGDB is quite impossible!
– with direct F5 execute, the breakpoints can’t be set at most lines, or never get hit.
– using the attach method (per tutorial steps: burning flash per nrfjprog, awaiting with ‘SysprogsDebuggerAttached’):
all I can see (VisualGDB, debug -suspend) is the app looping in an single idle task.

I verified both, Configuration Settings ‘Optimize for debugging’ and Compiler Options / Optimization level ‘Optimize debugging experience’
are active.

Note, as soon as I added more code lines to the source, the breakpoint displacement got worse,
especially when adding zephyr-os calls like k_msleep.
For me it looks like the generated HEX-code does not match to the source / ELF anymore?

QUESTIONs:
– is this 1.5.1 ‘NRFX’ example supported and tested with current VisualGDB?
– does SysprogsDebuggerAttached work automatically, or is there a debugger setting?

Thanks

[support]

Hi,

The specific examples come from the device vendors (Nordic in this case). We do not test every example on every device and generally advise contacting the device vendor if some of the examples don’t work.

That said,the Nordic devices are somewhat trickier to debug than other device families, because their proprietary network hardware may stop working if the core it stopped in a debugger for too long. In our experience, using non-intrusive debugging techniques (e.g. Fast semihosting and Live Watch) works better than the regular step-by-step debugging.

Another issue is that the NRFConnect SDK normally sets the optimization level to -Og instead of -O0, making GDB somewhat less precise. VisualGDB can override the optimization level to -O0 via VisualGDB Project Properties -> NRFConnect Project -> Optimization = Disable Completely, however it will increase the amount of memory used by the application (heap/stack) and may cause runtime errors for some examples.

We would normally advise the following steps to troubleshoot it:

1. Try completely disabling optimization. Do the breakpoints work correctly?
2. If not, try adding a hardcoded breakpoint to the same location where you would normally set a regular one:

   __asm("bkpt 255")

3. If the hardcoded breakpoint doesn’t work, disabling optimization has triggered errors (e.g. heap/stack overflows in the project).  You can then revert to the “optimize for debugging” setting and manually disable optimization for a select set of sources where you would like to have precise debugging. This can be done by editing CMakeLists.txt as shown below:

   set_source_files_properties(src/main.c COMPILE_FLAGS -O0)

The SysprogsDebuggerAttached logic should work out-of-the-box. However, the Zephyr thread enumeration in NRFConnect SDK 1.5.1 requires the following hotfix: VisualGDB-5.6.1.4142.msi

[ThomVisGdb04]

Hi

Thanks for the valuable tips, I will try them out in the next days, once I have the priority back to this platform.

[Author]

Posts