This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

After DFU Application at DFU_BANK_0_REGION_START is not valid

Hi,

I have a device with nRF52832 and firmware is composed of Bootloader (BL), softdevice (SD) S132 v2.0.0, application and I am using SDK 11.0.

I have created different firmware updates (BL, SD, App, BL+SD, etc.) in ZIP format (using nrfutil v2.2.0) and when I try to perform a DFU over BLE, I always end up with DFU_BANK_0_REGION_START (Addr: 0x0001C000) with all its content reset to 0xFFFFFFFF.

I use the application setting provided by Nordic support for nRF52 and I merge it together with the other HEX included in the ZIP files:

:020000040007F3    
:10F000000100000000000000FE000000FFFFFFFF05
:00000001FF

I have tried using the ZIP files provided in the SDK 11.0 in the example projects related to DFU usage, but even those fail. With the only difference that with those example ZIP files, actually the files get transferred (using Android app nRF Connect).

This is a sequence of events happening in my system when I try to perform a DFU (I have printed some log messages):

ble_evt_dispatch(): p_ble_evt->header.evt_id 16         -> BLE_GAP_EVT_CONNECTED
ble_evt_dispatch(): p_ble_evt->header.evt_id 18         -> BLE_GAP_EVT_CONN_PARAM_UPDATE
ble_evt_dispatch(): p_ble_evt->header.evt_id 80         -> BLE_GATTS_EVT_WRITE     
ble_evt_dispatch(): p_ble_evt->header.evt_id 81         -> BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST
ble_evt_dispatch(): p_ble_evt->header.evt_id 80         -> BLE_GATTS_EVT_WRITE
bootloader_dfu_update_process() update_status = 4       -> DFU_BANK_0_ERASED
ble_evt_dispatch(): p_ble_evt->header.evt_id 1          -> BLE_EVT_TX_COMPLETE 
ble_evt_dispatch(): p_ble_evt->header.evt_id 81         -> BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST
ble_evt_dispatch(): p_ble_evt->header.evt_id 80         -> BLE_GATTS_EVT_WRITE 
ble_evt_dispatch(): p_ble_evt->header.evt_id 80         -> BLE_GATTS_EVT_WRITE 
ble_evt_dispatch(): p_ble_evt->header.evt_id 80         -> BLE_GATTS_EVT_WRITE 
ble_evt_dispatch(): p_ble_evt->header.evt_id 80         -> BLE_GATTS_EVT_WRITE 
ble_evt_dispatch(): p_ble_evt->header.evt_id 80         -> BLE_GATTS_EVT_WRITE 
ble_evt_dispatch(): p_ble_evt->header.evt_id 80         -> BLE_GATTS_EVT_WRITE 
ble_evt_dispatch(): p_ble_evt->header.evt_id 80         -> BLE_GATTS_EVT_WRITE 
ble_evt_dispatch(): p_ble_evt->header.evt_id 81         -> BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST
ble_evt_dispatch(): p_ble_evt->header.evt_id 1          -> BLE_EVT_TX_COMPLETE
ble_evt_dispatch(): p_ble_evt->header.evt_id 1          -> BLE_EVT_TX_COMPLETE 
ble_evt_dispatch(): p_ble_evt->header.evt_id 81         -> BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST
bootloader_dfu_update_process() update_status = 6       -> DFU_RESET
bootloader_app_is_valid(): EMPTY_FLASH_MASK

Resetting
[After restarting] 

bootloader_app_is_valid(): Application at DFU_BANK_0_REGION_START is not valid!

Do you have any suggestions on how to make it work. I am pretty sure it is just a matter of creating the proper ZIP file and/or incompatibility of SDK/DFU Manager/Android App.

Thank you for the support.

Marco

  • I agree that that moving from the nRF52832 QFAA to the CIAA package should not cause any issues as they are both 512kB Flash and 64 kB RAM. Yes, please do that and you could also try to run the standard bootloader to see if you see the same behavior or not.

  • I will. Could you please confirm that using the latest nRFConnect/Toolbox would not cause any issue with legacy bootloader (SDK11) as long as I use the nrfutil v0.5.2? In addition it is not clear to me in which ZIP file I have to include the configuration file app_valid_setting_apply_nRF52832.hex (devzone.nordicsemi.com/.../combining-sd-dfu-and-application-hex-and-programming).

  • The nRFConnect and nRF Toolbox apps are backwards- compatible with the Legacy bootloader and nrfutil v0.5.2. You should not include the app_valid_setting_apply_nRF52832.hex file in a DFU image, you should only merge it with the BL hex when you're programming your device using a programmer and want the device to boot into the application and not stay in the bootloader. For DFU update the settings file should be omitted.

  • It seems I managed to make big progresses. Now the DFU process can transfer the whole image (application only) to the nRF52. However I get "[DFU] Remote DFU error: REMOTE DFU INVALID CRC ERROR" on nRFConnect app. I have printed a a log message:

    dfu_init_postvalidate(): received_crc 0x0002, image_crc 0xCCAD, image_len 63748
    

    I have checked other posts related to CRC error, but with no luck. I tried to upload another image (application only) and the received_crc is always equal to 0x0002. I have also tried the DFU with the BL+SD and the loge message reports 0x0002 again as received_crc:

    dfu_init_postvalidate(): received_crc 0x0002, image_crc 0x55C9, image_len 132076
    

    Any ideas about what it could generate this issue?

  • As an additional test I have checked for the m_extended_packet_length and the content of m_extended_packet[]:

    dfu_init_postvalidate(): received_crc 0x0002, image_crc 0xCCAD, image_len 63748, m_extended_packet_length 84
    0x02 0x00 0x00 0x00
    0x04 0xF9 0x00 0x00
    0x70 0xA4 0x54 0x7C
    0x63 0x7D 0xE3 0x72
    0x08 0x31 0x00 0x20
    0x05 0x00 0x5F 0xAA
    0x08 0x31 0x00 0x20
    0x03 0x55 0x23 0x4D
    0xA5 0x7D 0x08 0x0A
    0xBE 0xB6 0xB8 0x85
    0x38 0xBA 0x6B 0x0A
    0x4B 0xC1 0xA7 0x16
    0x94 0x65 0x7F 0x24
    0x7C 0x05 0xA2 0x44
    0x69 0xFD 0xE3 0x00
    0x90 0xF3 0xEA 0x1F
    0xB0 0x93 0xE3 0x40
    0x11 0xE0 0x3A 0x72
    0x7E 0x1C 0x57 0xEC
    0x55 0xE3 0xED 0xA6
    0x4F 0xA0 0x17 0x27
    
Related