sd_flash_write HardFault when softdevice is enbled

[Francois Mazard]

Hi,

I'm currently in trouble with the sd_flash_write function. I've already a library using this function running on the nRF52832 with the S132 softdevice. But when a tries to run the same code compiled for the S140 softdevice on the nRF52840, the function call get stuck in the hardfault handler.

I use the SDK version 15.2.0

If the softdevice is enabled, the hardfault always occurs at the address 0x24ADC and with the PC = 0x14a3a. But if the softdevice was never enbled, the function is perfectly working.

Do you have an idea why the function break the softdevice ?

I know the there are some other smart functons to manage the memory but I aready have an optimized library for the memory managment using the sd_flash_write function and sd_flash_page_erase.I don't want to redo all my library.

Regards

[Øyvind]

Hello, 

Can you please provide the whole error message you receive? 

Have you tried to do run 

nrfjprog - e

 and then reprogram?

Kind regards,
Øyvind

[Francois Mazard]

I already tries the nrfjprog -e and the nrfjprog --recover

There is no error msg, I have just the break point in the app_error_fault_handler with id = 1; pc = 0x14a3a and info = 0

Can you tell me what is the corresponding problem in the softdevice ?

Thanks

[Francois Mazard]

how much is the maximum size allowed ?

In my archive, I have included the sdk for an easier compilation. I removed it but you'll need to add it manually in the nRF5_SDK/nrf5_SDK_15.2.0 folder

TestFlash.zip

[Øyvind]

Francois Mazard said:

how much is the maximum size allowed ?

 I don't have a clear number, but I believe about 30-50MB is the limit. 
Edit: According to the admin of DevZone, it should be able to handle up to 1GB. Unfortunately, we are having some stability issues which causes errors sporadically in regards to file transfer.

Francois Mazard said:

In my archive, I have included the sdk for an easier compilation

This would explain the reason for the error.  A full SDK is about 500MB.

 

Francois Mazard said:

I removed it but you'll need to add it manually in the nRF5_SDK/nrf5_SDK_15.2.0 folder

 I was able to add all the missing files and got your code running. I was also able to reproduce the error but was not able to find the source of the error. The Hard Fault Assertion is due to flash writing, and it is taking too much time while something in the SoftDevice needs resources. I am discussing the issue with my colleagues and will get back to you. 

I tried to run my test flash code without calling the ble_advertising_init function but the problem still occur with the same PC

We see the same issue. And the ble_advertising_init() function does not start advertising, we cannot clearly see what is causing the assertion. But it does assert in the BLE_SoftDeviceFlashWrite() function. While waiting, please debug the BLE_SoftDeviceFlashWrite() function. 

Thanks!

[Francois Mazard]

Ok, I'll continue to investigate on my side.

Anyway, do you have a reference code for the sd_flash_write usage with the softdevice enbled ? If Yes can you sent it to me, It will be usefull for the debugging

Thanks

[Øyvind]

Francois Mazard said:

Ok, I'll continue to investigate on my side.

 Great, thank you!

Francois Mazard said:

Anyway, do you have a reference code for the sd_flash_write usage with the softdevice enbled

The only example I could find was in the ANT Bootloader example (\examples\dfu\experimental\ant_bootloader\).

volatile uint8_t mb_flash_busy = false;
/*
 * sd_flash_page_erase() and sd_flash_write() generates an event at SD_EVT_IRQHandler
 * Please include run this function inside SD_EVT_IRQHandler
 *
 */
void ant_boot_settings_sys_event_handler(uint32_t sys_evt, void * p_context)
{
    if ((sys_evt == NRF_EVT_FLASH_OPERATION_SUCCESS) || (sys_evt == NRF_EVT_FLASH_OPERATION_ERROR))
    {
        mb_flash_busy = false;
    }
}

uint32_t ant_boot_settings_save(ant_boot_settings_t * boot_settings)
{
    ret_code_t err_code = NRF_SUCCESS;

    mb_flash_busy = true;
    err_code      = sd_flash_write((uint32_t *) ANT_BOOT_SETTINGS_LOCATION,
                                   (uint32_t*)boot_settings,
                                    ANT_BOOT_SETTINGS_SIZE / 4);
    if (err_code == NRF_SUCCESS)
    {
        while (mb_flash_busy); // wait until it is done
    }
    else
    {
        return err_code;
    }

    return err_code;
}

uint32_t ant_boot_settings_clear(ant_boot_settings_t * boot_settings)
{
    ret_code_t err_code = NRF_SUCCESS;

    // Clears \ presets the bootloader_settings memory
    memset(boot_settings, 0xFF, sizeof(ant_boot_settings_t));

    // Erases entire bootloader_settings in flash
    mb_flash_busy = true;
    err_code      = sd_flash_page_erase(FLASH_LAST_PAGE); // last flash page
    if (err_code == NRF_SUCCESS)
    {
        while (mb_flash_busy); // wait until it is done
    }
    else
    {
        return err_code;
    }

    return err_code;
}

I hope this is of any help to you. 

Kind regards,
Øyvind

[Francois Mazard]

thanks, I'll look at it

[Øyvind]

Hello again,

We were able to find the source of the assertion. The code is writing too big chunks to the flash at one time, causing the error. This is explained in the SoftDevice Flash memory API documentation

However, this is a bug with the SoftDevice and is reported internally. A suggestion for a workaround is to write two times 512 bytes instead of 1024 bytes.

The best workaround is to use the Flash Storage (fstorage), which is written to handle bigger data and divide into smaller chunks, and handle bigger queues with data, without disturbing radio events / SoftDevice. There is an example here.  

Hope this solves the issue.
-Øyvind

[Francois Mazard]

thanks a lot

I will try to implement your work around in my library. I fail, I'll use the fstorage to manage my flash memory

I'll keep you informed asap

[Francois Mazard]

thanks a lot your workaroud is working. I updated my library with it

like always, the nordic support is awsome

[Marco V.]

Hello Øyvind, 

I have the same problem reported, even if I'm using Flash Data Storage Module (SDK 15.2).

The hardfault occurs when it's called sd_flash_write() after an fds_record_update().

The update is called inside a TWIS write event. In addiction, I still started advertising.

Could you please give me some advice on how to solve this issue?

Best regards,

-MarcoV

[Marco V.]

Problem solved. I had the TWIS irq priority too high, so it went into hardfault.