nRF DFU softdevice

RE: nRF DFU softdevice

Hung Bui — Mon, 01 Apr 2019 12:16:10 GMT

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.

RE: nRF DFU softdevice

sbu — Fri, 29 Mar 2019 15:43:02 GMT

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.

RE: nRF DFU softdevice

Hung Bui — Fri, 29 Mar 2019 14:17:27 GMT

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.

RE: nRF DFU softdevice

sbu — Fri, 29 Mar 2019 08:50:45 GMT

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