This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Segger Embedded Studio (SES) debug terminal fails to log some of the time.

I'm working on a few projects for for a smart home company. My machine is running Windows 10 and I'm on SES version 4.40. I'm using my dev board (a PCA10040) to program the products I am developing.

Rarely, when I go to run the program on the device after loading the code and reaching the start of main, I press play and the debug terminal has popped up but receives no data. My co-workers have seen this as well and all we do is reprogram the target and it works. I can work with that. However, one project I am working on, it has recently switched around to where it rarely shows the logs. I've gone back to other projects and they continue to load and log normally, but not this one. I've swapped dev boards and the hardware that I'm working on, but the problem remains the same. I've tested to verify that I can make no changes to the program and just wait and try after a little while, and it sometimes works. Quite often it does not still. I know the the application is running because I have tested device functionality and it works. The debug terminal launches, but it never shows data. I've tried connecting the RTT viewer from Segger too and I get the same result. I updated from SES 4.16 to 4.40 in the process and updated to the most recent J-Link drivers without any changes to this issue.

Still, every now and then it will log correctly. In my research to find a solution I encountered a few suggestions for making the logging work in later versions of SES after having done updates (mostly referencing this define "NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED"), but none of these seem to apply since it used to work and still works occasionally. Also adding in the fixes have not changed the issue. I think it's something in my project that fails to activate the output through the RTT, but I'm shooting in the dark. It's seems to be local to this project since none of the other projects are this difficult to make the debug terminal to log.

Where should I start looking?

Parents
  • Hi

    Are you using the RTT for something other than debugging in this project? Can you also confirm that you tried setting NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED to 0 in your sdk_config.h file?

    I've also seen an issue where newer versions of SES has issues logging SDK v.15.3 projects. In the SDK v.15.3 release notes, you can see that the SES version used for testing and verification was SESv.4.12, and this version has been confirmed output the debug info in the debug terminal, so I suggest you try v.4.12 to see if it may be a problem with your version of SES (I thought this had been fixed by now, but I'd say it's worth a shot).

    Best regards,

    Simon

Reply
  • Hi

    Are you using the RTT for something other than debugging in this project? Can you also confirm that you tried setting NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED to 0 in your sdk_config.h file?

    I've also seen an issue where newer versions of SES has issues logging SDK v.15.3 projects. In the SDK v.15.3 release notes, you can see that the SES version used for testing and verification was SESv.4.12, and this version has been confirmed output the debug info in the debug terminal, so I suggest you try v.4.12 to see if it may be a problem with your version of SES (I thought this had been fixed by now, but I'd say it's worth a shot).

    Best regards,

    Simon

Children
  • I have confirmed that definition is set to 0. I'm also not using RTT for anything else in this project.

    However, this morning the debug terminal has worked correctly every time I've started it. The computer has not been power cycled, the code was not altered since yesterday. When I left yesterday, it was maybe working once in 20 tries. Today it's worked every time, from my first program run  to my latest, after I have done some clean up on the minor changes I have been making over the past week. I was about to try rolling back, but the problem is not repeatable as of this morning. If and when it comes back, I will try your next suggestion of rolling back to 4.12.

    I'm still interested in finding the cause and I won't be surprised if this issue shows up again. I'll keep this updated.

Related