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

What is sd-id 0xCAFE?

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).

Parents
  • HI Collin, 

    0xCAFE is the FWID used for alpha versions of the SoftDevice. 

    If you set the sd-req to 0xFFFE, then the bootloader will accept any SoftDevice.  

    /** @brief SD_REQ_ANY_VERSION field value which indicates that any SoftDevice version is valid. 
     *
     * @note This is used by external application in case SoftDevice version compatibility isn't needed.
     */
    #define SD_REQ_ANY_VERSION (0xFFFE)

    I also checked the  softdevice and application test images in nRF5_SDK_15.3.0_59ac345\examples\dfu\secure_dfu_test_images\ble\nrf52832 and they do indeed set 0xAF as the sd-req. This is incorrect and should have been 0xB7 as you have correctly pointed out. My guess is that this is due to the scripts creating the images not being updated from SDK v15.2.0 ( which used S132 v6.1.0) to SDK v15.3.0. 

    I will report this internally. 

    Best regards

    Bjørn

  • Thanks for the answer, makes sense about the scripts.

    Another note, I found that the DFU bootloader will not accept a softDevice package with sd-req 0xFFFE, since it is not running a softDevice. So, the first time I run a board, the UART DFU needs sd-req of the softDevice package to be 0.

Reply Children
No Data
Related