Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

RK — Tue, 11 Jun 2019 21:27:18 GMT

At this point I'd really suggest going back to basics. Write a hello world program using the SES template which if I remember correctly imports all the RTT headers for you and you can call RTT directly. Just have it print, wait (you can use a simple loop) then print again. If it doesn't, just pull them in yourself and do it. See if that works with the debug terminal. If not, load up the code and connect up the JLink RTT viewer and see if you can get that to work.

When you get to the point you can see RTT output, next thing is to find the RTT calls buried under the NRF macros, put a breakpoint in them and ensure they are actually being called.

That thread Johannes linked to mentioned the RTT tab on the JLink control panel as another place you can see raw RTT output - have you looked there?

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Jason — Tue, 11 Jun 2019 17:58:48 GMT

I've just tried this but I still see nothing in the Debug Terminal, even using printf.

I tried putting this at the top of my sdk_config.h

#define NRF_PRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0

and when that didn't work I tried changing the sdk_config.h to

#ifndef NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED
#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0
#endif

When I look in my subversion diffs for that file, this is the only line that is changed. This is for

C:\nRF5_SDK_15.3.0_59ac345\examples\ble_peripheral\ble_app_uart

The example uses both of these lines just before advertising_start() (line 738)

printf("\r\nUART started.\r\n");
NRF_LOG_INFO("Debug logging for UART over RTT started.");

If I type some text into the Debug Terminal by pressing keys on my keyboard then they appear in the window. So it's not because of editor colours or something silly. When I step the debugger I see nothing from printf or NRF_LOG_INFO

I also checked my solution options but they look fine.

Being paranoid cant hurt so I also changed the printf to printf("UART started."); to remove the escaped characters entirely but it still shows nothing. I then repeated the line 20 times to see if it was some weird buffering thing.

My J-Link control panel looks like this

All of this is running on Windows 10 but I had the same problem with Win7

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Vidar Berg — Tue, 11 Jun 2019 13:42:28 GMT

Thanks for the clarification. I'll report this as bug internally.

Regards,

Vidar

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

SEGGER - Johannes — Tue, 11 Jun 2019 11:50:15 GMT

Hi Vidar,

This is only related to Embedded Studio, not the J-Link Firmware or Software.
RTT viewer might behave differently then Embedded Studio.

I don't know if there is a difference between your nRF52840 and nRF52832 projects.
ES will always behave this way with \r\r\n and from our point of view this is an issue in the SDK.

Regards
Johannes

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Vidar Berg — Tue, 11 Jun 2019 11:28:57 GMT

Thanks Johannes, it solved the problem on my side at least. However, is this expected to happen after updating the Segger driver? Also, the same FW (before applying workaround) worked with RTT viewer and was only able to reproduce it on 52840, not nrf52832.

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

SEGGER - Johannes — Tue, 11 Jun 2019 08:41:00 GMT

Hi Jason,

There is an issue with the SDK that transforms \r\n into \r\r\n, which clears a line before doing a line break in the Debug Terminal.

See this thread: https://devzone.nordicsemi.com/f/nordic-q-a/45985/nrf_log-not-working-on-segger-embedded-studio?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending

Is this the issue in your case, too?

Regards
Johannes

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Jason — Fri, 07 Jun 2019 20:59:41 GMT

Thank you, I have now sent them an email

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

RK — Thu, 06 Jun 2019 21:05:36 GMT

You may also want to go to the Segger forums and ask there. They support JLink and SES and even if they aren't Nordic experts and can't probably comment on the code, if you're running a standard example right out of the SDK which ought to log and doesn't, they may be able to help. The entire RTT logging component is all Segger and they (well Rowley who makes SES) integrated it with the debug terminal several years ago. Especially if you're having version mismatch issues they can often help get that straightened out.

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Jason — Thu, 06 Jun 2019 20:57:01 GMT

OK thanks, I tried to uninstall everything but I had problems with missing uninstallers (see pic below) I installed 622g but when I tested again I still didn't see anything in the debug terminal. I used Revo uninstaller to forcibly remove the broken stuff. I then reinstalled Segger Embedded Studio and made sure I didn't install the latest J-Link driver. I then installed 622g again. But it still didn't work.

When I look in the J-Link Control panel it still shows the version as 6.44d

I also tried manually copying the JLink_x64.dll into the C:\Program Files\SEGGER\SEGGER Embedded Studio for ARM 4.16\bin folder but it seems to stop the J-Link control panel from launching.

I'll give up for tonight! Thanks for your help

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Vidar Berg — Thu, 06 Jun 2019 12:24:36 GMT

Ok, so I see the same problem after updating the latest Segger driver (v.6.46C). Please try to uninstall the version you installed, then install an older version, 622g for instance. The antivirus SW is preventing me from downgrading for some reason so couldn't verify this on my side.

The log should be displayed in the debug terminal.

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Jason — Wed, 05 Jun 2019 21:06:49 GMT

reinstalled j-link driver but it didn't fix it. Then I reinstalled Segger embedded studio for ARM V4.16 (64-bit) Hobbyist license. It's still the same. I can see from my Subversion diff that my nRF5_SDK_15.3.0_59ac345 has no diffs in that example.

When I do "Build and Debug" I can see it pop up the progress bars. I know it's updating the software because I've been able to develop various examples. I press F5 to run in the debugger and nothing appears in the "Debug Terminal". When it breakpoints at 3 minutes I still see nothing in the "Debug Terminal"

Am I looking at the wrong window? Is it called "Debug Terminal"?

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Jason — Wed, 05 Jun 2019 15:38:32 GMT

Yes, 3 minutes sounds right. Latest SES I think. I moved from Windows 7 to Windows 10 last night so tonight I'll try testing again and reinstalling jlink and maybe SES. Thanks for your excellent help 😀

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Vidar Berg — Wed, 05 Jun 2019 13:21:08 GMT

Thanks for testing this. It indicates that it's not a FW problem at least. What version of SES and which OS are you using? You can try to update to the latest J-link driver and see if that helps. Link: https://www.segger.com/downloads/jlink/

[quote user="JasonR"]And after about a minute or something I noticed that it had stopped here (with id=16385 which is NRF_FAULT_ID_SDK_ERROR)[/quote]

Sure it's not 3 minutes? Then it would be expected as the app attempts to enter deep sleep (system OFF) after 3 minutes of inactivity, which is not possible in debug mode.

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Jason — Tue, 04 Jun 2019 19:16:04 GMT

Ok so I tried running ble_app_uart with a debug build and I still get no trace output. And after about a minute or something I noticed that it had stopped here (with id=16385 which is NRF_FAULT_ID_SDK_ERROR)

As you can see there is still nothing printed in the Debug Terminal window in the lower right of the display.

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Vidar Berg — Tue, 04 Jun 2019 12:26:41 GMT

Hi,

It should be sufficient to change the logger backend to RTT. To narrow down the issue, please try the ble_app_uart example which has logging over RTT enabled by default and see if you get the same result.

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

Jason — Mon, 03 Jun 2019 22:46:16 GMT

Thank you.

Do you mean logging macros like NRF_LOG_ERROR for example? Because I do not see those lines (or any others) appearing in my Debug Terminal window.

Running in the debugger, debug build. v15.3. Connected to my PC with USB.

If I set a breakpoint or step through the code I can see that it is asserting with NRF_FAULT_ID_SDK_ERROR.

Thanks again for your help.

RE: Do I need to buy a Segger external debugger to get debug trace in Segger embedded studio?

RK — Mon, 03 Jun 2019 21:45:04 GMT

Yes if you want to use actual trace you need a Segger external debugger which supports trace. Trace uses a separate set of lines from the ARM microprocessor. Not many people actually need to use trace however.

Your second quote has nothing to do with the first, note that doesn't even mention 'trace'. You can program it using the onboard JLink just as it says you can but the onboard debugger does not support the trace outputs just as your first quote says.

None of that has anything at all to do with what you have enabled in your sdk_config.h, RTT, which is Real Time Terminal which allows a log output via any JLink device which then appears in the terminal pane of SES. It doesn't use the trace pins, it has nothing to do with trace. This is probably what you actually wanted in the first place, just use the logging macros with those defines enabled and the log will go to SES.