I am trying to update the firmware of a nRF52832 chip, embedded on a custom board, from SDK 12.1 to SDK 15.2.
For that I need to do a DFU OTA from SDK 12.1 to SDK 15.2, and both firmware have a Secure Serial UART Bootloader, an Application, and a Softdevice (SoftDevice 3.0.0 for the SDK 12.1 application, and SoftDevice 6.1.0 for the SDK 15.2 application). The Secure Serial UART Bootloader currently used with SDK 12.1 is very similar to the one given in example with SDK 15.2, and has always worked fine when doing an application DFU OTA (so updating only the app). Update packages come from a GSM chip, via UART, which communicates with the nRF52832.
In order to do so, I followed the procedure explained here: https://devzone.nordicsemi.com/f/nordic-q-a/43995/dfu-14-2--15-2-bl-sd-app.
I generated private and public keys, built both bootloaders with this public key, then created the DFU package containing BL+APP+SD with SDK 15.2:
nrfutil pkg generate --hw-version 52 --sd-req 0x8C,0xAF --application-version 1 --application nrf52832_xxaa.hex --softdevice s132_nrf52_6.1.0_softdevice.hex --bootloader nrf52832_xxaa_mbr.hex --bootloader-version 2 --sd-id 0xAF --key-file private.key BL+APP+SD_15.2_v5.zip
Still following the procedure, I then flashed the device with SoftDevice 3.0.0 hex file (nRF5_SDK_12.1.0_0d23e2a\components\softdevice\s132\hex\s132_nrf52_3.0.0_softdevice.hex), and then with the SDK 12.1 serial UART bootloader.
But after having received the INIT packet and when handling the EXECUTE OBJECT command (0x04), nRF52832 sends [0x04, 0x0a], 0x0a being the response code for NRF_DFU_RES_CODE_OPERATION_FAILED.
By debugging the bootloader, I found out that this comes from the dfu_handle_prevalidate() function (called in dfu_handle_signed_command()), in the dfu_req_handling.c file, more precisely when checking for required SoftDevice version:
The call to SD_FWID_GET(MBR_SIZE) returns as expected 0x8C, which is the current SD version installed (s132_nrf52_3.0.0), but the p_init->sd_req array only contains 0xAF, so SoftDevice 6.1.0 ID, and not 0x8C, even if it was specified in the --sd-req argument when creating the DFU package.
It actually works if I write --sd-id 0x8C,0xAF instead if --sd-id 0xAF when creating the DFU package, but this doesn't seem normal as if I understood well we should only specified here the new SD ID, so 0xAF in my case.
I know the procedure I followed was actually for a BLE bootloader case, but I assumed it was the same for a Serial UART one, In my case I am also trying to update a much older SDK than 14.2...
What could be the reasons of this issue ?
Thank you in advance for any help.
To eliminate the potential SDK 12.1 factor, I tried the same operation but this time trying to upgrade from SDK 15.2 to SDK 15.3. In this case, the DFU package contains a BL (nRF5_SDK_15.3.0_59ac345\examples\dfu\secure_bootloader\pca10040_uart), an APP (nRF5_SDK_15.3.0_59ac345\examples\ble_peripheral\ble_app_hrs_freertos) and SD (nRF5_SDK_15.3.0_59ac345\components\softdevice\s132\hex\s132_nrf52_6.1.1_softdevice.hex) from SDK 15.3.
The chip is flashed with SoftDevice 6.1.0 (nRF5_SDK_15.2.0_9412b96\components\softdevice\s132\hex\s132_nrf52_6.1.0_softdevice.hex) and BL (nRF5_SDK_15.2.0_9412b96\examples\dfu\secure_bootloader\pca10040_uart).
And I have the same results. If I generate the DFU package using this command line, supposed to be good if I follow the procedure explained in the thread:
nrfutil pkg generate --hw-version 52 --sd-req 0xAF,0xB7 --application-version 1 --application nrf52832_xxaa.hex --softdevice s132_nrf52_6.1.1_softdevice.hex --bootloader nrf52832_xxaa_mbr.hex --bootloader-version 2 --sd-id 0xB7 --key-file private.key BL+APP+SD_15.3.zip
The MCU answers [0x04, 0x0B, 0x07] to the NRF_DFU_OP_OBJECT_EXECUTE command (0x04), so an extended error NRF_DFU_EXT_ERROR_SD_VERSION_FAILURE.
By debugging, I can see that the sd_req_check() function returns FALSE:
But if I generate the DFU package with:
nrfutil pkg generate --hw-version 52 --sd-req 0xAF,0xB7 --application-version 1 --application nrf52832_xxaa.hex --softdevice s132_nrf52_6.1.1_softdevice.hex --bootloader nrf52832_xxaa_mbr.hex --bootloader-version 2 --sd-id 0xAF,0xB7 --key-file private.key BL+APP+SD_15.3_v2.zip
So using --sd-id 0xAF,0xB7 instead of --sd-id 0xB7 I don't have this issue anymore and sd_req_check() returns TRUE:
But again this doesn't seem right (and creates further complications) and I also find that the only difference between the two is the value of the sd_req_cnt variable, which is 1 in the first case and 2 in the second, even if p_sd_req stays the same.