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, 
The response code [0, 96, 192, 2] is a little bit strange to me. When it started with a 0 and 192 doesn't really match the response code as far as I remember. 
There must be something wrong with the bootloader. If it's possible to debug the bootloader to check why it send such response we would be able to figure out. 
In addition the response code came just 3uS after the CRC request also suggested that there must be something wrong. Usually the CRC calculation takes a few hundred micro seconds. 

I'm thinking og there is a chance that there's been a RAM/Flash hardware issue.

[Harry]

Ok Hung, I will try to debug it. If I recall correctly, it worked fine when it runs from debugger. I'll let you know.

In the meantime, would you mind giving me the answer of these questions?

Harry said:

I added the retry mechanism to the pc-nRFutil, so it seems that retry mechanism for checksum may not be ideal for this communication protocol, is that right?

I was wondering, does the bootloader store the last offset in bootloader settings - to be used to pick up where it left? I would imagine people may encounter this situation when a FW upgrade failed - then they won't be able to retry without doing full erase. Is there a recovery mechanism without full chip erase?

[Hung Bui]

Hi Harry, 

Could you let me know the SDK version of your bootloader ? 

Our current bootloader does support recovery mechanism and the offset value is stored in the bootloader setting. 

I have tried this on BLE DFU but it should operate the same on UART DFU (if implemented properly in nrfutil). 

[Harry]

Hi Hung,

The SDK I use is V15.3.0.

[Hung Bui]

Hi Harry, 
If you use bootloader in SDK v15.3 the resume feature should already be implemented. You can find in the nrf_dfu_settings_t struct in nrf_dfu_types.h the write_offset property. It's the current offset of the part of image that it's already received. This value is sent to the DFU master when it start the process. And it's stored in flash.