nrf9160 Embedded Studio compile debuggable code

[JanK.]

Hello everyone,

I am completely new to Nordic and the Segger Embedded Studio and have some problems getting started. I followed the guide (https://www.nordicsemi.com/Software-and-Tools/Development-Kits/nRF9160-DK/GetStarted) and am able to compile the assert_tracker example. I noticed that the board is unable to connect to the mobile network (probably service provider related, thats not the issue here) and tried to debug the problem. However, debugging is nearly impossible because the toolchain compiled every c-file (except the ones in the assert_tracker directory, main.c and orientation_detector.c) into a library (*.a) and linked that library. So everytime I enter a library function when debugging I have no idea whats happening. In this particular case the program gets stuck in lte_lc_init_and_connect() and never returns.

How can I get the Embedded Studio to compile object files instead of libraries so I can have some debug context?

This is probably an easy thing to fix but being new to the IDE, the Zephyr project and its build system as well as to Nordic MCUs I have no idea where to look.

Thank for your help,

Jan

[Håkon Alseth]

Hi Jan,

 

 

I noticed that the board is unable to connect to the mobile network (probably service provider related, thats not the issue here) and tried to debug the problem. However, debugging is nearly impossible because the toolchain compiled every c-file (except the ones in the assert_tracker directory, main.c and orientation_detector.c) into a library (*.a) and linked that library. So everytime I enter a library function when debugging I have no idea whats happening. In this particular case the program gets stuck in lte_lc_init_and_connect() and never returns.

How can I get the Embedded Studio to compile object files instead of libraries so I can have some debug context?

This is probably an easy thing to fix but being new to the IDE, the Zephyr project and its build system as well as to Nordic MCUs I have no idea where to look.

There's normally two reasons why you get stuck in the boot up.

One being that the link can take several seconds in order to connect to a cell tower, and the other might be due to entering debug mode, as there's an errata where you can get stuck in debug mode:

https://www.nordicsemi.com/DocLib/Content/Errata/nRF9160_EngA/latest/ERR/nRF9160/EngineeringA/latest/anomaly_160_17#anomaly_160_17

 

One reason why you cannot properly debug might be the optimization level.

By default, the project is setup to optimize for size. To change this, you can add this symbol to your prj.conf, then reconfigure the project (ie: import it again in SES) https://docs.zephyrproject.org/latest/reference/kconfig/CONFIG_NO_OPTIMIZATIONS.html 

Could you edit prj.conf and add "CONFIG_NO_OPTIMIZATIONS=y" and see if this helps?

 

Kind regards,

Håkon

[JanK.]

Hi Håkon,

thanks for your reply.

Håkon Alseth said:

One reason why you cannot properly debug might be the optimization level.

This could also be an issue as well but I don't get to the point where it would bother me. It seems to me as if the IDE is unable to find the source code (if I right-click on a function and select "Go to declaration" it jumps to the definition in the header file instead. This is true for all functions except the ones implemented in the main.c/orientation_detector.c). Therefore when I stop execution in the debugger or single-step while being inside one of these functions, I don't actually see the c-code corresponding to the program counter. All I have is the dissambled memory which is not that helpful.

So maybe a setting in the IDE has to be adjusted? I couldn't find anything related and a google search turned nothing as well. But maybe someone here has an idea?

Thanks,

Jan

[Håkon Alseth]

Hi Jan,

 

Goto definition (alt+G) should work, as well as go to declaration (alt+shift+G), although the rest you list up, I can confirm is missing at this time. SES nordic edition for nRF91 is still in the development phase, and there are several things that can be improved upon, like the overall debugging experience, as the only thing you can actively peek into is globals at this time. I will report this internally.

 

Kind regards,

Håkon