nRF DFU softdevice

[sbu]

Hello,

I am not able to update the softdevice from 6.0.0 to 6.1.0. This usecase is useless as I am in dev stage of my product. However I need to be sure I will be able to update later the softdevice.

So I program my IC with the 6.0.0 and an old app version and use DFU over UART to program both SD and App. The DFU is properly able to program the application (when softdevice is already up to date). the DFU controller stack is homemade (STM32). So here is what I have done. I generate a SD+APP package using nrfutil. as , I add the binaries directly in my code and send it to the bootloader.

I start by the softdevice to avoid any validation error. But it always stop at 96% of the download, after that the bootloader stop responding. I am always stuck after the offset 0x23000 of the binary, but the size is 0x2436C. Before that, everything goes fine. I am pretty convince that it consider the new SD is too big but I do not know how to solve this problem.

As it failed, the controler try to restart the process. So it select the init packet, and CRC and size are already OK. then it select the binary to restart the download where it was, but the answer is not correct as offset = 0x100 despite the fact that the CRC is correct during the whole process of the first 0x23000 bytes. I set the PRN to 1 so that every packet is confirmed and CRC is checked. And it is correct during the whole process. It looks like it overlaps the next section.

I do not change any default organization of the memory, so the SD start at 0x1000, the app at 0x26000 to 0x381D8.

I am in single bank mode.

Hope you can help.

Regards

[sbu]

I may precise, that I just to in force dual bank mode, and also stucked after 0x23000 bytes sent.

[Hung Bui]

Hi Stephane, 

Please clarify your setup. You are doing DFU from an STM32 to a nRF52832 chip via UART ? The image is stored in STM32 flash and the firmware to transfer the image to the nRF52 is written for the STM32 ? 

You haven't done any modification on the NRF52 bootloader code ? 

There is no option in the DFU target code to receive softdevice and application at the same time. So it will need to be sent to the nRF52 in 2 shots. First one should be the SD and after that the application. 

Since it can't be combined, we should focus on updating each of them separated. 

I assume you managed to do an application update from STM32 to nRF52 ? 

Have you tried to update the NRF52 with a PC to test ? And make sure the bootloader would work in both S132 v6.0 and S132 v6.1

Capture logging on the nRF52 when you receive image would help identify the issue. 

[sbu]

Thanks a lot for your reply.

Yes you're completly right for the setup.

I have done very light modification on the bootloader. I add a GPIO to give STM32 the current mode of the code (app or bootloader), and use a custom_board.h.

I am not combining both files, I am trying to push 4 files at the end. starting with the 2 soft devices files.

I spend some time today since my post here to enable the NRF_LOG module. It seems that the inactivity timeout is the problem. It is restarted if I understand properly only once per object (size 0x1000 in my case). I disable this timeout (value 0) and seems not to finish the process. still unclear why it happens always at the same address, but as I do have a lot of checksum calculation on the STM32 side, maybe when reaching the end of the file, it takes to much time... I wanted to trigger the event on every valid packet received so that I can keep a reasonnable inactivity management, but I am not sure this is a good idea.

One possibility to reduce the time to transfer one object is to increase the MTU. MTU is 0x83, so 64bytes after slip decode, which is in fact quite small. Any reason for this value ? any risk to increase it ?

One more thing, I set PRN to 1, because otherwise, the nRF seems to have an overflow somewhere. I don't think it is an uart overflow, but more either a flash write or event overflow.

I have not testing from a computer, as I do not have any USB/UART 1.8V converter. But yes, I manage to update the app using the same process, but the app is smaller that the SD for now. maybe with a bigger app, I will have the same issue.

Anyway, as it seems to be an inactivity issue somewhere, I will deal with it.

[Hung Bui]

I would suggest to get a nRF52 DK and perform PC UART DFU with that, then you can have a reference UART trace (using a logic analyzer for example) that you can refer to. 

I don't think PRN has to set to 1. We store data into flash on every NRF_DFU_OP_OBJECT_WRITE packet. There are some buffers and transmission doesn't need to wait for flash write to finish. 

I would suggest to print out some logging on RTT for example, to find out why there is a restart. I don't see the difference when transmitting the application image and softdevice image. If there was any issue with the size of the softdevice, it should happen by the end of the transaction (or at least after you have received certain amount of the softdevice image). 

Please let me know if you figure out something.