Flash erase fails on NRF52832CIAA (chip used in the Murata MBN52832 module)

[razvan1t]

Hi,

I have a custom implemented DFU that I used in many nRF52832 designs. 

This one in particular fails when I am calling  nrf_fstorage_erase. I am trying to erase 40 pages at once, starting at address 0x50000

The function returns success but it hangs and after a while I get this error

<error> app: ERROR 4 [NRF_ERROR_NO_MEM] at ../../../../lib/nRF5_SDK_15.3.0_59ac345/components/libraries/1
PC at: 0x0002E071
<error> app: End of error report

I thing the whole system froze and that is caused by timers piling up in some internal queue (just a guess).

The root cause of the problem is erasing the flash.

Also, very interestingly, the same code works flawlessly on the NRF52832-DK board.

It fails on the Murata module, which contains the nrf52832-CIAA chip.

Maybe you guys can help me determine this chip model exactly.

the FICR INFO.VARIANT register ix 0x41414531 but that exact code is not in the datasheet.

I would appreciate a solution to this problem.

Raz

[razvan1t]

           if (swap_erase_page(0, swap_get_page_count(), swap_erase_callback) == NRF_SUCCESS)

                    return;     //we do not send the response at this time

                else

                    response_code = BLE_RSP_ERROR;  

          

It gets called in the main() loop since I am using the scheduler. I also give it a callback that gets called when nrf_erase finishes.

ret_code_t swap_erase_page(uint32_t page, uint32_t count, swap_callback_t callback)

{

    APP_ERROR_CHECK_BOOL(callback != 0);

    APP_ERROR_CHECK_BOOL(page < SWAP_PAGE_COUNT);

    NRF_LOG_DEBUG("SWAP ERASE: %u", count);

    l_swap_callback = callback;

    return nrf_fstorage_erase(&swap_fstorage_instance, swap_fstorage_instance.start_addr + page * SWAP_PAGE_SIZE, count, NULL);

}

This code works in as few designs using the nrf52832 in the QFN package. It fails on CIAA

[bjorn-spockeli]

The count variable passed to nrf_fstorage_erase in swap_erase_page, is this 50? Do you see a difference if you divide the erase operation into smaller ones, i.e. two 25 page erases or five 10page erases?

Best regards

Bjørn

[bjorn-spockeli]

The QFN and CSP packages have the same silicon die so there should not be any functional difference between the two package variants. 

razvan1t said:

Nope. It only works if count is 1.

 Ok, so calling nrf_fstorage_erase() with len > 1 results in NRF_ERROR_NO_MEM being returned? Or does it just hang?

What is NRF_FSTORAGE_SD_QUEUE_SIZE defined to in sdk_config.h?

Best regards

Bjørn

[razvan1t]

The call returns NRF_SUCCESS but hangs and after some time I get the error I attached at the beginning. I think because it's blocking something internally. 

[bjorn-spockeli]

Oh, so its not nrf_fstorage_erase that returns NRF_ERROR_NO_MEM, its another function. I see now that you stated this in the original question.  Which function is located at 0x0002E071? 

[razvan1t]

the NO_MEM... error comes from app_timer.c at line 445

I also just discovered that another project that is similar runs well... I will have to see what is different between them.

It's weird though that even the one that is not working it runs on the NRF52832-DK but not on the Murata module.

Maybe the lack of RTC crystal? I am using SYNTH though.

[razvan1t]

Looking at the code now, it looks like there is nothing at line 445 that could throw that error so it means it's coming from an interrupt. probably the RTC and it just happens the ionterrupt interrupted at line 445 in app_timer.c

[razvan1t]

Bjorn. I found the problem. Turns out I was blocking the main loop, waiting for an IO to finish and since I am using the scheduler that would not give enough time to the erase operation to continue in a reasonable time. (I take from this that the erase operation happens in the main loop too if I use the scheduler?).

The timers were not executing either because of the blocked main loop and they were piling up until the list was full.

Moral: Don't block the main loop when developing with the Nordic API if you are using the scheduler. Thanks for looking into it too!

Raz

[bjorn-spockeli]

HI Razan, 

Happy to hear that you found the cause of the issue! Yes, if app_sched_execute is prevented from running then the queued events will not be handled within reasonable time. 

Best regards

Bjørn