• State Verified Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 62 subscribers
  • Views 828 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 124754
Options
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

Knowing NVMC operation is finished inside BLE event

Jonathan

(nRF51822, but also concerned with nRF52832, SD130, SDK 12.1)

I'm trying to write/erase flash from a bluetooth event handler. As it's been outlined in other questions, while being in the event handler, other events aren't fired (like NRF_EVT_FLASH_OPERATION_SUCCESS), as outlined here: devzone.nordicsemi.com/.../ and in another much better answered question that I can no longer find.

So whenever I write/erase, I wait the following way:

  while (NRF_NVMC->READY == NVMC_READY_READY_Busy)
  {
    nrf_delay_us(100);
  }

After what I check the result (check that the whole page is FF, or check that my data was properly written). However, my issue is NRF_NVMC->READY is set to 1 very quickly, while the erase hasn't finished yet, causing my firmware to believe the flash erase failed (because the page is not full of FF).

Am I doing anything wrong? Any way to improve this? Thanks!

  • 0

    Hi Jonathan,

    I don't think it's a good solution. The reason NRF_NVMC->READY is set to 1 very quickly is that the flash operation may not have started when you check that yet. The softdevice schedules the flash operation, it may delay the operation until the BLE event is finished for example. What you should do is to move your operation out of the event handler and wait for NRF_EVT_FLASH_OPERATION_SUCCESS in main context.

  • 0

    Thanks! I will investigate that lead! I know ideally it should be out of the event handler, however that makes the complete code considerably more complex, splitting everything into a lot of callbacks. Down the road I'll probably resort to it but if in the the meantime I can avoid it, I will...

Related