This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

zip combining BL+SD+APP cannot be uploaded in DFU

Hello I tried to do a application update with my own key and it does work.

But then I tried to create zip with all 3 parts: APP+BL+SD (application+BootLoader+SoftDevice) and that did not work. It copied something but then it end up in DfuTarg. And application was not updated (SD and BL was same in DevKit and in dfu.zip).

Do you know what can be wrong?

I used BL from example: bootloader_secure

I used APP from example: ble_app_hrs_freertos

I used DL from SDK12 package: s132_nrf52_3.0.0_softdevice.hex

my priv key was: -----BEGIN EC PRIVATE KEY----- MHcCAQEEIKjaCIfnnMU5VMsQ4/NCFAQXsZ9p6O3CHdxD2m7tQUceoAoGCCqGSM49 AwEHoUQDQgAE4gRlWO8tIPwDUTLE+47AvKdLNz6GA2CRkAPJPkPwXBwidZTkvJ4s NZqST0+RSH1yufVzVwRX4+HCyU/VmFyRLg== -----END EC PRIVATE KEY-----

my public key was: __ALIGN(4) const uint8_t pk[64] = { 0x1c, 0x5c, 0xf0, 0x43, 0x3e, 0xc9, 0x03, 0x90, 0x91, 0x60, 0x03, 0x86, 0x3e, 0x37, 0x4b, 0xa7, 0xbc, 0xc0, 0x8e, 0xfb, 0xc4, 0x32, 0x51, 0x03, 0xfc, 0x20, 0x2d, 0xef, 0x58, 0x65, 0x04, 0xe2, 0x2e, 0x91, 0x5c, 0x98, 0xd5, 0x4f, 0xc9, 0xc2, 0xe1, 0xe3, 0x57, 0x04, 0x57, 0x73, 0xf5, 0xb9, 0x72, 0x7d, 0x48, 0x91, 0x4f, 0x4f, 0x92, 0x9a, 0x35, 0x2c, 0x9e, 0xbc, 0xe4, 0x94, 0x75, 0x22 };

my batch file was:

set APP="d:\Python27\Scripts\nrfutil.exe" 
set HEX="examples\ble_peripheral\ble_app_hrs_freertos\pca10040\s132\arm5_no_packs\_build\nrf52832_xxaa.hex"
set BL_HEX="examples\dfu\bootloader_secure\pca10040\arm5_no_packs\_build\nrf52832_xxaa_s132.hex"

%APP% pkg generate --application %HEX% --application-version 0xff --softdevice s132_nrf52_3.0.0_softdevice.hex --bootloader %BL_HEX% --bootloader-version 0xff --hw-version 52 --sd-req 0x8c --key-file priv2.pem out.zip

I tried to update with android K + nRF connect. I also tried to use MCP I did connect to DfuTarg I list services but DFU button was not enabled.

Parents
  • Ok, I found the problem. It is the bug I gave the link to above. In Secure DFU the DFU Library 1.03 (and before) fails to get the ZIP content type: github.com/.../ArchiveInputStream.java The softDeviceSize and bootloaderSize are both 0, as there is no such information in the manifest file (there was in legacy DFU). But applicationSize is >0. So the type returned is APPLICATION, instead of SD+BL+APP. Then, the app sends app.dat, instead of sd_bl.dat as an init packet. But then, when reading the actual content, it reads the sd_bl.bin (which is bigger than the size specified in app.dat). Therefore, after sending 8 parts it fails, it simple does not expect more data. I'll publish the DFU library 1.0.4 soon and all the apps using it soon.

Reply
  • Ok, I found the problem. It is the bug I gave the link to above. In Secure DFU the DFU Library 1.03 (and before) fails to get the ZIP content type: github.com/.../ArchiveInputStream.java The softDeviceSize and bootloaderSize are both 0, as there is no such information in the manifest file (there was in legacy DFU). But applicationSize is >0. So the type returned is APPLICATION, instead of SD+BL+APP. Then, the app sends app.dat, instead of sd_bl.dat as an init packet. But then, when reading the actual content, it reads the sd_bl.bin (which is bigger than the size specified in app.dat). Therefore, after sending 8 parts it fails, it simple does not expect more data. I'll publish the DFU library 1.0.4 soon and all the apps using it soon.

Children
Related