I am debugging a strange issue regarding UART DFU. I am using the SES project in .\nRF5_SDK_15.3.0_59ac345\examples\dfu\secure_bootloader\pca10040_uart_debug\ses
I erase my MCU with J-Flash Lite, then debug the project, which flashes the MBR and the bootloader FW.
The prebuilt softdevice_s132.zip and hrs_application_s132.zip in secure_dfu_test_images\uart work well. I can flash those with nrfutil dfu serial (softdevice_s132.zip and then hrs_application_s132.zip, then board blinks and advertises).
However, I had trouble DFUing any other packages. I tried on the precompiled .hex files with my own key.pem and modified dfu_public_key.c.
I generated s132.zip with
C:\Python27\Scripts\nrfutil pkg generate --hw-version 52 --sd-req 0 --sd-id 0xB7 --softdevice s132_nrf52_6.1.1_softdevice.hex --key-file private.pem s132.zip
and generated hrsApp_s132.zip with
C:\Python27\Scripts\nrfutil pkg generate --hw-version 52 --sd-req 0xB7 --application-version 1 --application hrs_application_s132.hex --key-file private.pem hrsApp_s132.zip
If I then erase the nRF52, debug the UART_DFU project, and attempt to send the files, the softdevice works. Then the firmware resets, activates the SD, then resets, sees no app and stays in DFU mode. This makes sense and is good.
However, when I then dfu the new hrsApp_s132.zip, I get "Extended Error 0x07: The array of supported SoftDevices for the update does not contain the FWID of the current SoftDevice."
I paused the debugger in sd_req_check() function, getting volatile uint32_t testVar = _SD_FWID_GET(MBR_SIZE);
That variable, testVar, is 0xCAFE. I don't have any idea what that is. The function sd_req_check() returns false, because the sd-req of the app is set to 0xB7, which is what the 6.1.1 s132 release notes say the ID of s132_6.1.1 is.
Can anyone tell me what this 0xCAFE is? If I run "nrfutil pkg display .\softdevice_s132.zip" it rsays that sd_req is 0xCAFE, 0xAF. This seems to indicate that 0xCAFE is some debug/any value (0xAF is s132_6.1.0's FWID).