DFU succeeds but flash is erased

[brett_anderson]

I'm setting up the DFU using the example project in SDK 12.3. The only changes are a custom entry using GPREGRET, and a custom exit of a button press. I have removed the button entry from the example, and my button for exit is on pin 14. The exit is only for the case where the bootloader is entered, but the user does not actually want to do the update.

I've tested the entry and exit multiple times.

I have generated my own keys. The firmware update is for the application only, using the keys.

I am able to find the device, enter the bootloader, start the dfu process and watch it finish successfully on my phone. nrfConnect reports that the application was transferred successfully.

In the bootloader with a debugger, I am able to confirm that the application gets to: nrf_bootloader_app_start(MAIN_APPLICATION_START_ADDR);

If I read back the flash: nrfjprog --family nrf52 --memrd 0x7f020 0x0007F020: 00000001 |....|

The application just never runs. What I then noticed is that if I read back the entire flash to a file, there is no application.

nrfjprog -f nrf52 --memrd 0x00 --n 0x80000 >> working.txt (done after a program by nrfGo Studio)

nrfjprog -f nrf52 --memrd 0x00 --n 0x80000 >> uploaded.txt (done after a 'successfull' dfu update from my phone.

If I look at the working file, as you would expect starting at 0x29000 I see flash contents matching the size of the application (~94k). If I look at the updated file, I see nothing but 0xFF from 0x29000 until the start of the bootloader (0x78000).

I am using SD332. I have all of the headers and defines changed over.

working.txt uploaded.txt dfu_update.zip Any thoughts as to why it would tell the phone it succeeded, but clearly have not written the flash?

[brett_anderson]

So, a little more info for anyone who sees similar behavior. I did some additional testing.

1. Full erase, programmed just the soft device and bootloader with a clear settings page. This worked!

2. Full erase, programmed with the soft device, bootloader and my settings page. This failed the same way as before.

So I went back and remade my settings page and this seems to have fixed the problem. So my question to Nordic is, what could I have done to the settings that would allow it to boot to the application from reset, enter the bootloader, perform an update and report that everything worked, but not actually program the flash?

I'm guessing it has to have been a CRC error?

[Bjørn Kvaale]

Great to hear that you figured out where the error is located! What is the difference with the clear bootloader settings page & your own settings page? Also, is this DFU a single or dual bank update? Talked to another application engineer here at Nordic & it seems like the bootloader skips the application image transmission.

[brett_anderson]

The 'clear' bootloader settings is made with this command:

nrfutil settings generate --family NRF52 --bootloader-version 1 --bl-settings-version 1 _settings.hex

If I generate the settings this way and then merge and flash the bootloader, I can still run the debugger from Eclipse. If I do this and then run the DFU, it creates the problem I saw.

[Bjørn Kvaale]

I wonder if it could be something with the bootloader and/or settings version numbers? Have you tried adjusting the version numbers to values greater than 1 to see if that works?

[brett_anderson]

I have not. Once I figured out that it worked when I specified the application, I wrote two scripts. One that erases and programs with the application for deployment, and one that erases and programs without the application for debugging. I only test the DFU on the deployment versions now.

If you want, I can go back and do some testing once I get this version released. That won't be until the end of the week though.