How to see debug messages via RTT channel without running it from debugger?

[Harry]

I am working on an existing Bootloader project, it uses the Bootloader from the SDK with added custom thin layer on top of it. It runs on a custom board.

I can see the debug messages fine when I run it from the debugger (SEGGER J-Link) - on RTT channel (using J-Link RTT Viewer).

However, when I let it run standalone (with debugger connected to the board), I can only see debug messages from our custom code. Once it jumps into Bootloader SDK component, there is no debug messages anymore.

Did I miss some configuration in sdk_config.h? Or something else?

[Hung Bui]

Hi Serene, 
Maybe your issue is the same as this ? https://devzone.nordicsemi.com/f/nordic-q-a/20708/rtt-logging-from-application-started-by-bootloader

[Harry]

Thank you so much, Hung. I found that it's something with reset mechanism. It works ok now.

Btw, is it OK to ask you a side question? Or do you want me to post a new case?

Have you seen the flash erase operation interfering with DFU transfer? I know that the CPU is halted during flash erase. When I debug the Bootloader, the PC side (pc-nrfutil) didn't get a response for "CalcChecsum" command (sometimes at other places). And one time, I saw the debug message indicated it's doing "fstorage erase" operation. The problem is, when I run it from debugger, 99.9% of the time it worked fine - so I couldn't use breakpoints to step through.

[Hung Bui]

Hi Harry,
You may need to recompile the bootloader with debug mode (no optimization and DEBUG in the preprocessor symbols) and put some logging to check what went wrong. You may need to move the bootloader down in flash to make more space due to larger flash size. 

I don't think flash operation would cause any interference here. The DFU protocol was designed so that the master always wait for the DFU target to be ready before continue. We will need to look into why the bootloader hung. 
You usually saw it crashed at the end of the DFU process ? 
Please also try to test on other hardware board, just to avoid any possibility that the flash on the DUT was worn out. 

[Harry]

Hi Hung,

Yes, I already did all that.

The crash varies, somestimes at "failed to send init packet", but mostly at "CalcChecsum". No, it's not at the end of DFU, as I played with PRN value.

Thanks for pointing out about possibility of worn flash. Among approximately 100 brand new boards (our custom boards), we encounter 3 failed boards. There are 2 boards that are intermittent, and one board that is always failed. When I load/program everything via J-Link (nRF Connect for Desktop), this one board works fine. So, I don't know if it's worn flash.

At first I thought it's something with the PCB layout or tracks, but the main application is able to run fine at much higher baudrate (1Mbps). DFU runs at 115200 bps.

Any idea?

[Hung Bui]

Hi Harry, 

Sorry for late response I was on vacation last week. 
The fact that you mentioned it worked 99% with the debugger suggest that it might not be the worn flash. 

I'm more into the issue of UART communication. Please try to do some intensive test of the UART communication. 

Since both RTT and UART logging is not possible, you may want to debug using GPIO toggling to check where in the bootloader the issue occurred.