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.

[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. 

[Harry]

Hi Hung, no worries for the late response.

Btw, the main application runs at higher baud rate, 1 Mbps via UART, and there is no occurrences of drop packet or any other UART issue.

I suspected the electrical characteristic when the board power up, or after soft reset. Btw, we have 2 type of devices, one uses reset line to do soft reset with small time window waiting for DFU trigger packet, the other one is purely hard reset (power reset). The common thing between both of them are that DFU is performed right after a reset.

[Hung Bui]

I see. Please try to put some delay before you start the DFU process. There could be a chance that the device was not ready before you send data. 
I assume you are using HWFC ? 

[Harry]

I put 20 ms, maybe it's not enough. I will try to make it larger.

Unfortunately, no, I am not using HWFC.

[Hung Bui]

The UART bootloader is designed with HWFC. If you don't use HWFC you may need to change the baudrate to very low. Let's star with 9600bps. The reason is that there is some flash erasing involved when you do DFU. If you don't have HWFC there is a chance that your will have buffer overflow because the CPU is hang when there is flash activity on going. 

[Harry]

Hi Hung, sorry for the delayed response.

I finally had a chance to try 9600 bps. I have a board that's consistently failed at the same spot. So, even with 9600 it's still failed. The failure is the embedded side didn't send the checksum ("CalcChecksum" no response). When I did a retry from the PC side (resend the command, 0x03), got mismatch checksum.

Am I not supposed to do the retry?

Any other idea I can try?

[Hung Bui]

I don't have further idea except that you may need to run the bootloader in debug mode and check why it doesn't response to the CalcChecksum command. I suspect that it crashed earlier than that or it didn't receive the packet properly. 
But could you confirm that you only see the issue in 3 boards and only one board always failed ? When you test the other 2 board at 9600 would they also failed ? 

[Harry]

Hi Hung, 9600 still failed on one board. The other two work, but I need to test more to check.

The weird thing is, when it failed, the packet sequence is different, there are discrepancies. I used the same file, I don't understand why would the payload/sequence be any different, or why would it's parsed differently. It almost looks like the issue is in the file parsing.

Here's what I meant:

At the beginning:

At the end:

Let me know what you think.

[Hung Bui]

Hi Harry, 

Thanks for the trace. What I can see in the trace is that the main difference is the offset of 141 bytes in the Failed case. This showed that the bootloader already received the init packet and because of that the DFU master (I assume you are using nRFutil ? ) skip sending the init packet and simply execute it.

After that the DFU master continue to transfer the image until it finish the first object and ask for CRC check. The failed board didn't response to the request and on the retry it responded with the CRC of the init packet (exactly the same as in the first response to the init packet Select command at the beginning). So for some reason the bootloader didn't accept the first object of the application image. 

What I would suggest is to try to do a chip erase to clean the board and try again. Then you can record a trace with out the offset as in the current test.