• State Verified Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 86 subscribers
  • Views 275 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 355223
Options

BLE Interrupts and Flash Operations

cemile nur damnali

Hi,

I use flash read operations at the BLE interrupts, because I need some of the stored informations. However, while I am doing another flash operations and BLE interrupt arrived at the same time the firmware stucks at the wait_for_flashready(&fstorage);.  

Before doing any flash operation (Read/Write/Erase) I am looking for f_storage readyness. The BLE Interrupts are crucial and when they arrived they have to evaluate by firmware, but also I have to solve this conflict. What should I do?

Should I remove the flash read operations in BLE Interrupts?

Sincerely,

Parents
  • 0

    Hi,

    Like you say, the BLE interrupts are very important and time sensitive, and needs to be done quickly. That you want to store something from these are understandable as well though, but you should rather do this with a workqueue. For more on how to make workqueues, see here.

    Regards,

    Elfving

  • 0 in reply to Elfving

    Hi Elfving,

    Unfortunately I cannot use RTOS in my project. I want to know the real cause of the conflict to produce a real solution. I remove all of the flash read functions in the BLE interrupts and as I see there is no problem no more. But I am not sure about the problem's real cause though. 

    For short, did this conflict happened because of this state or was it due to something else?

    Sincerely,

  • +1 in reply to cemile nur damnali

    Are you using the bare-metal SDK, nRF 5 SDK, or plain bare-metal? I guess the solution is the same though, you need some sort of buffer or scheduler of tasks you can do outside the interrupt.

    cemile nur damnali said:
    But I am not sure about the problem's real cause though. 

    I guess the actual fault depends on the situation, but generally, BLE tasks are very time-sensitive and need to be handled right away. You can study this further by looking at the error you've gotten, but I believe the answer will be the same. It is worth noting that if you have something else you need to do that is equally time-sensitive, we've developed multi-core SoCs for this very reason - you can eg. get the extra core on the 54L to do this flash writing. 

    Regards,

    Elfving

Reply
  • +1 in reply to cemile nur damnali

    Are you using the bare-metal SDK, nRF 5 SDK, or plain bare-metal? I guess the solution is the same though, you need some sort of buffer or scheduler of tasks you can do outside the interrupt.

    cemile nur damnali said:
    But I am not sure about the problem's real cause though. 

    I guess the actual fault depends on the situation, but generally, BLE tasks are very time-sensitive and need to be handled right away. You can study this further by looking at the error you've gotten, but I believe the answer will be the same. It is worth noting that if you have something else you need to do that is equally time-sensitive, we've developed multi-core SoCs for this very reason - you can eg. get the extra core on the 54L to do this flash writing. 

    Regards,

    Elfving

Children
No Data
Related
Terms of service