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

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

Tom Nantais — Fri, 23 Dec 2016 15:35:10 GMT

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.

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

Hung Bui — Fri, 23 Dec 2016 12:43:54 GMT

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.

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

Tom Nantais — Fri, 23 Dec 2016 12:14:02 GMT

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.

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

Hung Bui — Fri, 23 Dec 2016 08:58:24 GMT

Hi Tom,

I don't know why you need step 2, generating the bootloader setting ? It's not in the instruction in the doc. You only genrate the bootloader setting and merge it when you want to merge the application and flash the application with the bootloader at the same time.

To test with the stock .zip in the SDK, please simply:

Compile the debug bootloader
Flash the softdevice and then the bootloader
Check if the bootloader advertising, then do DFU update from nRFToolbox or NRFConnect

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

Tom Nantais — Thu, 22 Dec 2016 18:07:38 GMT

@Hung Bui: I'm starting to wonder if I'm using the DFU mechanism correctly. I start by clearing the flash, then programming the s132 and bootloader-plus-settings hexfile using nrfjprog via J-Link. The bootloader should start at 0x75000 because I haven't changed the linker settings. At this point, there's no application (and the bootloader settings were generated with no --application specified). Then I transfer the application via nRF Toolbox. Please see edit 3 above for testing with SDK example.

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

Hung Bui — Thu, 22 Dec 2016 16:08:20 GMT

@Tom: the example .zip is located at \examples\dfu\ble_dfu_send_hex\test_images_update_nrf52832.

I just had a look into your hex file, seems that the whole 2 banks are empty. You sure you don't do any flash erasing with your application ?

Besides testing with the example .zip file, you can also try to test with the example in the SDK such as the ble_app_hrs.

Where did you set the start address of your bootloader ?

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

Tom Nantais — Thu, 22 Dec 2016 15:51:16 GMT

Thanks very much Hung Bui. I've attached the hex dump and app package. I'm sure I've just made a simple mistake. I'll try dfu_test_app_hrm_s132.zip with the default debug bootloader from the sdk?

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

Hung Bui — Thu, 22 Dec 2016 11:41:45 GMT

Hi Tom,

From the log , it seems the CRC comparison returned invalid. The CRC of the image copied to 0x1f000 doesn't match with the crc from bank 1. This is pretty strange. Could you read the whole hex dump after you do DFU and send me that ? You may want to include the .zip file you used .

If you try with the test .zip example and the debug version of the bootloader, would it work ?