bootloader problem - slow upgrade over UART

[Wojciech Puchar]

I have already implemented DFU update in our one product. Which have fast USB interface and fast "lag-less" UART interface to nRF chip which is used as our bluetooth central.

DFU update works. Sometimes - very rarely - fails, nRF bootloader simply resets after command 03 (checksum).

So we mostly ignored the problem - once per say 50 updates update fails, user will simply repeat it. And end user will rarely (if ever) do software update for nRF chip.

Now we made same bluetooth central module for our older product that have interfacing chip for onewire bus.

It's slow. Not just onewire, but the rest too.

interfacing chip can perform bootloader entry and switch to onewire-UART bridge mode.

My software update program do works as expected - which is confirmed by connecting FTDI uarts to both RX and TX ports on nRF side.

Everything is sent properly and received properly - just slowly.

I don't mean slow UART speed (it's 57600 in both cases) but sending commands (most of the are command 08 - firmware data block) are sent one by one with quite large delays.

Delays may be random. Still - everything is sent properly which is confirmed.

The problem is that now nRF bootloader resets so often that you have to be lucky to succeed to update firmware. Say one per 5 attempts works.

What is a reason of these resets?

[Einar Thorsrud]

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. 

[Wojciech Puchar]

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

[Einar Thorsrud]

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.

[Wojciech Puchar]

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

[Einar Thorsrud]

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