Debugging strategy: how to make the OB JLink on nrf52dk work seamlessly (across several programs...)

[MuRa]

Hello all

I am playing around with the nrf52dk for the last 14days, done some progress, namely the TWI is working and I can read the sensor and printing its values in the debugger inside, when the emStudio is working, without a problem, I have even started to use the RTT, indeed, JScope works all good...

The major problem I am having is with the " Debug terminal " within the emStudio. The JLink has to be reset all most every time after the programm has been flashed... how to make this stable? I am using basic nrf_log...  In addition, if you develop the RTT , do you even bother with this terminal? Or should I rather switch to the UART, putty and alike, what is the strategy usually with regard to the debugging processes ? However, I am not sure , can both be used at the same time :)

In previous setup the Arduino's pritnout and plotter was used and its design was just good enough to get the job done, indeed, the JScope looks much more sophisticated, faster, etc. however, I would like to have an option to define the thickness of the line in JScope, I still did not figure out how to use the zoom on y axis... 

So far I am running the program from the emStudio , and scanning is done in the JScope, however, can this be synchronized and automatically use the preview in JScope... etc.

Please let me know what kind of a strategy are you using when debugging? Maybe I am not using the code properly, and is this why the emStudio debugging terminal has issues, needs to be reset almost every time, a bit annoying ...  , or is something else , has any of you experienced similar issues? 

Best.

[MuRa]

Hello Edvin and thank you for your reply, help, as you might noticed I am rather new to this...

"When the chip is reset, you need to reconnect the RTT viewer (or JScope, if that is what you are using). To be honest, I haven't seen JScope before now. Are you using this for logging, or to monitor the value of variables?"

You have you are asking the question I should be asking :) 

Indeed, I am using ses for the seeing actual text, while I am using the JScope to see, monitor that graph that is produces by the sensor values ...

Since I am using several outputs from the sensor it is much easier to observe the data on a graph...

"My understanding is that you want to monitor the log, and you have tried to monitor the RTT log using an "external" tool, like RTT Viewer while you are debugging in Segger Embedded Studio (SES), is that correct?"

Yes! Hence I have given the Arduino as an example... all in one, so, I guessed that Segger tools, like JScope will work along the SES internal debugger as well, I am still convinced that it should, but I am not sure should "the master" of this debugging be the SES or it does not matter, eg. is it necessary to start the debugging process within the SES and then move to the JScope and just use the scanning over there, or how does someone integrate those two? As you can imagine once you see the values you get the idea and you want to change it, which happens in the SES, and reflash and then back to the JScope and so ... and this is step when the JLink becomes unstable...

"Looking at JScope, it looks like a nice tool, but I have never seen it being used before. Did you use this with the nRF? If so, what are you using it for?"

I am using several prox sensors so reading of the values requires some kind of measurements that is relevant to the timing and particular environment, distances during the interaction ... so it is much easier to observe the values on a graph ... I guess the Segger would be better off with integrating the JScope directly as an integral monitoring application..,, that would be wonderful. Indeed, once working via the RTT is a bit different, but not impossible nor confusing, a rather good tech, however, if this could be operated within a single program like another screen within the SES etc. that would be an amazing tool ! That would not be annoying as it is now, when flipping between different programs :) otherwise a rather useful tool, at least for me! Experienced similar tool from the Arduino and to be honest the simplicity did its magic! Anyway, will studied in detail and will setup an environment that will work just as good, hopefully...

Looking back into the instability of the JLink, it is funny, because I have tested several other examples from the NRF SDK  and debugging rather works without a problem, indeed, there is no sensors readings involved etc. so I am still wondering , if I am reading the sensors values ok, it may be the problem of getting to fast the data from the sensor and it's all configuration setup, will have to go back to the draying board and test that out...

 Best.