bootloader problem - slow upgrade over UART

RE: bootloader problem - slow upgrade over UART

Einar Thorsrud — Mon, 07 Mar 2022 08:13:51 GMT

I have described how you can debug the bootloader. Please follow the suggestions.

RE: bootloader problem - slow upgrade over UART

Wojciech Puchar — Mon, 07 Mar 2022 07:55:39 GMT

As i've already wrote i already checked it. bootloader has errors, not my side.

RE: bootloader problem - slow upgrade over UART

Einar Thorsrud — Fri, 04 Mar 2022 12:45:16 GMT

Good to hear you see progress. This is not something that seems familiar so I think it is worth continuing to look at things outside of the nRF. Can you log the UART traffic from the PC as well as from a logic analyzer to see if the UART lines has the expected data or not when you get the CRC errors? If it does, it is worth looking more into the bootloader. In that case, I suggest starting with a debug bootloader and observing the RTT log to see what that contains. That may give some pointers on what to d o next.

RE: bootloader problem - slow upgrade over UART

Wojciech Puchar — Fri, 04 Mar 2022 06:48:02 GMT

Already partially found what is a problem. If every slip packet is sent without pauses (this could be done with buffer in interface chip) things gets far better. Now 4 per 5 attemps to update works. but funny some 4kB blocks gets CRC eraors and are repeated - in spite they are sent properly.

But bootloader is clearly buggy. in uart reception side.

BTW update over uart with nrfutil do fails the same way, just rarely

RE: bootloader problem - slow upgrade over UART

Einar Thorsrud — Thu, 03 Mar 2022 13:02:44 GMT

Hi,

In order to find out why the bootloader resets you need to debug in the bootloader. The most typical reason for a reset is some sort of error being detected by an error check, and the default error handler will do a reset in order to recover. If you can, the simplest would be to test with a debug bootloader with RTT logging (example projects with that are suffixed with "_debug"). With RTT logging enabled you will hopefully learn more about what happens in the bootloader. If not, you can do other things like set a breakpoint in the error handler and see if it is hit before the reset. And if so, trace back from there.