Looking for a reason flash might be 0xff's after OTA DFU

[Tom Nantais]

Hi, I'm trying to install the BLE buttonless DFU template onto a nRF52 (PCA10040) eval board using the secure bootloader example (with s132, version 12.2 of the SDK) via nRF Toolbox. There's no application there to begin with, but I've specified that in the bootloader settings. The process seems to go correctly (takes about 30 seconds, progress bar moves smoothly) and the toolbox gives a message that upload is complete. After that, I'd expect to find application code in flash starting at 0x1f000, but it's all 0xff's. I'm attaching the output from nrfutil pkg display for the app. Is there some common mistake that would lead to this situation? Thanks very much.pkg.txt

Edit: I ran the debug build of the bootloader and I am seeing what looks like a successful transfer but a bunch of erases after reset and a CRC error. I'm attaching the log. Thanks for any insight! errorlog.txt

Edit 2: As requested, here is the full hex dump and app package file. template5.zip nrf52_hexdump.txt.zip

Edit 3: I tried the process using the example bootloader (secure_dfu_secure_dfu_ble_s132_pca10040_debug.hex) and sample zip file (dfu_test_app_hrm_s132.zip) and got the same failure. For clarity (and because I think I'm still making a simple mistake) here are the steps I took: (1) source bin/activate (2) nrfutil settings generate --family NRF52 --bootloader-version 1 --bl-settings-version 1 blsettings.hex (3) mergehex -m secure_dfu_secure_dfu_ble_s132_pca10040_debug.hex blsettings.hex -o bootloaderpkg.hex (4) nrfjprog --eraseall -f nrf52 (5) nrfjprog --reset --program bootloaderpkg.hex --family NRF52 (6) Turn off eval board and turn back on holding down button 4 (7) Start up JLinkExe and JlinkRTTClient for logging purposes (8) transfer dfu_test_app_hrm_s132.zip from iPhone using nrf toolbox. When I do that, I get this log exampleprogramlog.txt

[Tom Nantais]

Thanks Hung Bui, I will try it as soon as I get to the office. I believe the bootloader hex file that I found in the SDK is already correctly compiled with the s132 embedded. About the bootloader settings, I was going by 1(e) in these instructions because we were generating our own firmware to be installed OTA. Last night, I was concerned that the problem might be that I was erasing important settings in the UICR with --eraseall and not restoring them before programming.

[Hung Bui]

Hi Tom,

The version by default will be 0 and you don't really to write the bootloader setting manually. You may need one if you want to pre-configure the bootloader setting .

The bootloader setting is updated after each success DFU update.

Please try to use the hex file you compiled your self, not the pre provided hex (even though it should work also). If you complie the bootloader hex your self then it's not included the softdevice.

Please follow the instruction in "Testing" section in the link you pointed to above. Ignore step 4.

[Tom Nantais]

Thanks very much Hung Bui -- flashing just the bootloader + s132 works. Next, we'll try it with our app and keys. The example could perhaps be improved by making clearer the conditions for including bootloader settings. The way it reads now suggests you want to include those settings anytime you're making your own firmware, but people want to experiment with installing their own firmware over BLE, in which case you don't want to include bootloader settings.