Debugging, NRF_LOG, Segger Embedded Studio Problems

[brianreinhold]

I saw something in the list that might help but I have learned that if I go there I lose all the work I did to get here

I am having major problems with Segger Embedded Studio

• NRF_LOG_x does not print either through the UART and putty OR RTT in SES [Manually set in the sdk_config.h file] since CMSIS Wizard is not present
• The CMSIS Configuration Wizard is NOT present in my Tools.xml
• Debug breakpoints are not hit unless it is in the main() part of main.c and when hit not in the code, only if a debug window to the left of the code
• I can step line by line if I start and use F10/F11 from the start (do not use F5 and a break point) but never once I use F5 and a break point.

The only thing I can think of is that somehow the installation of SES got really corrupted or I am missing a major step. I have no idea how to fix.

Yet the code I have does partially run - it advertises, gets connected to, responds to service discovery, gets two characteristic descriptors enabled but then when I try and write from the client the write times out. I am not surprised that there are issues with the code as I have ported a SoftDevice only project from nRF51 and Keil.

But being unable to debug or even print to RTT (this is new for me) or via the UART and putty (the latter worked fine in the Keil project) is not helping.

Any help would be great. (Yes I have seen the debugging video and that's how I know my Tools.xml is corrupt).

[brianreinhold]

I understand that anytime I set a break point in the middle of any transport protocol the transport is going to die, but the point is one CAN set a break point and at least analyze what is happening at that time. Currently I cannot set any break point and have it hit (such as in my Ble connection event handler). If I set a break point in the main function before the 'infinite loop' that will get hit.

There is definitely something wrong in the setup of SES and the port. I have tried various things. Following the instructions for the port of Keil nrf51 projects failed but I am guessing it's because it is out of date with my latest SES download. Some of the interfaces referred to in the instructions no longer exist and some of the links in the instructions led to nothing - so there I had to guess.

I tried to build some of the provided template projects (latest SDK - 17+)  to see if I could start with that but they failed to build. There were missing include files that I did not bother to chase down.

However, I have been able to build and run the thermometer example. (I use my own client app which is well tested in the field for many health devices, both proprietary and standard as well as HDP). SO I have been playing with the various combinations of log settings in the SDK_config.h file to see what works and what doesn't. I have gotten NRF_LOG to work across the UART using putty (that's what I did for my Keil project) and I have gotten RTT to work. I have not yet tried setting breakpoints in the middle of the code yet.

Out of real desperation I may start with this project and port that over to the sd_ only code of the Keil project (it would then be compatible with my pc-ble-driver nrf52840 dongle project like the Keil project is). That is a lot more work than I wanted to do but its how I started in Keil. The ugly thing is the direct port (with some changes in the sd_ APIs - very few) basically works. Something happens when the client tries to write - but I have been unable to debug or print in that project. Seems like I am so close yet frustratingly far.

[Simonr]

Hi again

It's very difficult to deduce what exactly has happened here to cause this I'm afraid, but I got some input from one of my colleagues after discussing your issue with him.

The bad debugging likely has something to do with the debug optimizations set in the project after it was ported to SES. Can you check what the Optimization Level is set to in your project options. If it isn't already, try setting this to Level 0 for fast compilation and the best possible debug experience. Selecting None here might cause a less than optimal debug experience for instance.

Best regards,

Simon

[brianreinhold]

You may be right here. I took the hts example program (unmodified) and switched to debug, did learn to get RTT working by trial and error with the SDK_config.h settings (as well as the NRF_LOG via UART and putty) but a break point in the connection event would not be hit. Optimization was set to None. So I put it to 0 and the breakpoint was hit.

SO now I might be able to go back to my ported project and debug it!

[Simonr]

Glad to hear that, please verify the answer if you found it helpful, so DevZone users with the same issue in the future can find a solution more easily.

Best regards,

Simon

[brianreinhold]

Haven't succeeded yet with my project. Getting double \r\r even though I turned off that auto CR thing in the FPRINTF

So there are still a lot of issues that make it impossible for me to validate anything