In heart rate monitor, what is the purpose of m_memory_access_in_progress?

[tyler]

I am working through the heart rate monitor central ble device code on Nordic SDK 8.1. I noticed that the variable

bool m_memory_access_in_progress = false;  /**< Flag to keep track of ongoing operations on persistent memory. */

is created, but I can't figure out what the use of it is. From what I can see it's only set to true when pstorage_access_status_get() returns a number that isn't 0, and all other times m_memory_access_in_progress is false. The thing is I don't see it being passed into any functions or ever checked so what is the purpose of having it?
As a side note the board I'm using just has an nRF51822 without any storage added onto it.

[endnode]

This is to signal that nRF5x flash operation is ongoing, nothing to do with external storage. One of rarely moments when you can block entire nRF5x MCU for long milliseconds is flash page erase operation (as you can read in the manual) so any FW which uses time-sensitive activities (e.g. radio) and writes to internal flash tries to limit thee activities when it is safe to do them. More on this in countless Q&S on this forum...

[tyler]

Ok. I moved the declaration to a header file (sys_evt.h):
static bool m_memory_access_in_progress = false; And then moved all the scanning operations (for example scan_start()) to a different file that includes sys_evt.h using #include"sys_evt.h". Will this cause a problem?

[endnode]

You should tell after doing some thorough tests...

[tyler]

Ok. Considering it has to do with writing to flash that means it could work sometimes and not others depending on if it's trying to write when something else is writing correct? Like if there is a problem with it trying to write when there is a flash operation it could work sometimes and not others?

[endnode]

No, no, no. Stop assuming, read at least 10 Q&S on this topic (here on the forum) and particular chapters of nRF51 or nRF52 reference manual/specification (preferably twice). Both writing and erasing of the flash blocks the MCU. Because there is only one computing "core" in ARM Cortex-M design anything what would need to be handled (e.g. interrupt) needs to wait. Because write is almost instant it's usually not a problem but erase can take anything between 1 and 23 milliseconds. Therefore if you use Nordic BLE stack then you should run all flash operations through Soft Device API because they get queued (so no, nothing could be "lost", no probable game plaid here) and stack let them through only when it's kind of sure that it won't hurt it if MCU goes out of service for up to ~23ms. And in case you run some intense activity (such as link with low connect. interval) then...

(1/2)