NRF51822 crashes in pstorage_raw_store

[stpaul]

Hi,

I'm writing the f/w upgrade function.

The device is NRF51822, and I use nRF51 SDK_v5.1.0.36092 with s110_nrf51822_6.0.0_softdevice.hex.

I refereed to the example "device_firmware_updates" with 2 banks, but put the processes in my executing code instead of bootloader.

I can write the new f/w to DFU_BANK_1_REGION_START -> 0x00028400. The CRC is good and sd_softdevice_forward_to_application successfully forward to 0x00028400 and boot up in bootloader.

When I try to do the same thing that write a new f/w back to DFU_BANK_0_REGION_START -> 0x00014000.

The function pstorage_raw_clear returns okay and the area is cleared, but system always crash in pstorage_raw_store.

Then the system reboot from original address(DFU_BANK_1_REGION_START) but hangs. If I reflash the f/w again in DFU_BANK_0_REGION_START, then bootloader can boot again from DFU_BANK_1_REGION_START.

Do I do something wrong? Should I keep any information in DFU_BANK_0_REGION_START or modify the start up procedures? I would like to do f/w upgrade sequentially in each bank, because I don't have DFU mode support in my products.

Thank you for any help.

[Nguyen Hoan Hoang]

I got the dfu to work by reducing the PSTORAGE_MIN_BLOCK_SIZE to smaller number (8 in my setting) instead of the default 0x10. It is defined in pasturage_platform.h. Never worked when set at 0x10

[stpaul]

Hi Nguyen Hoan Hoang,

Thank you for your reply.

The value PSTORAGE_MIN_BLOCK_SIZE was also modified as 1 in my code, because I use only one block for boot setting. The macro BLOCK_SIZE_CHECK verifies block_size of pstorage_module_param_t in function pstorage_register. If I keep the value in 10, the function returns NRF_ERROR_INVALID_PARAM.

I had made my f/w upgrade work now by write the image to 0x00028400 and then check the CRC. If the CRC is matched, the f/w size will be stored to boot setting block and restart the system. Bootloader then start and check the boot setting, move the f/w to 0x00014000 and forward the application. This is the way example "device_firmware_updates" does.

I did not have time to check the full processes and assembly codes, but I think there may be some functions or memory settings related to the address 0x00014000. If I forward the application to 0x00028400, the code could run because there is still a copy in 0x00014000. The function crashes because I clear the codes in 0x00014000 when I try to flash the f/w.

Although the bootloader became bigger because the flash function, and the flash be cleared / written 2 times for moving the f/w to 0x00014000. The result is okay for me now.

Cheers, Paul