Why Flash access should be restricted in radio operation?

RE: Why Flash access should be restricted in radio operation?

Vidar Berg — Tue, 12 Jan 2016 11:26:04 GMT

pstorage functions can be called at any time. Pstorage and the SD flash api will make sure that the flash operations are performed between radio events.

RE: Why Flash access should be restricted in radio operation?

xtting — Fri, 08 Jan 2016 02:38:00 GMT

Hi, Berg

I have some question about it.

Does this mean I can't call pstorage_store any time, when the BLE is work? If I called it, the BLE connection may be lost, right?

How could I do if my BLE-sensor product need to real-time restore the data when BLE connection works? Need I disconnect the connection, then save to flash, then automatically reconnection it? But out purpose to set the transter interval is 1s, you said the save time should be more than 1s up-to 10s, right?

RE: Why Flash access should be restricted in radio operation?

jorbar — Fri, 08 Jan 2016 01:30:53 GMT

Thanks RK.

I understand your explanation. I'm a beginner at Nordic solution. then it's my curiosity why those inconveniences should be exist.

in nRF51 manual, description says CPU is not stalled when CODE/DATA are fetched from RAM even in flash write operation. this fact is the cause of my addtional question.

But with your description, it is cleared that because SoftDevice code is always located in flash, cpu can be halted in radio operation with simultaneous flash access..

RE: Why Flash access should be restricted in radio operation?

RK — Fri, 08 Jan 2016 00:32:13 GMT

Which series are we talking about here, nRF51 and nRF52 are slightly different. It's not really anything to do with reading from flash, it's writing. tWRITE, tERASE and tERASEALL can take from a few 10s of microseconds to 1/4 second (depending on chip). Those are the operations which need to be scheduled.

Yes it is true on the nrf51 series that a flash erase can happen with the CPU running as long as code is being read from RAM, but a flash write always stops the CPU and anyway the softdevice code runs from flash,not RAM, and that's the code which has strict timing requirements. For the nRF52 series it's not even specified (anywhere I can see) that code can run at all during a page erase.

So the flash module, which deals with flash writes and erases, needs to be carefully scheduled between radio events to ensure the link stays alive.

Why does it matter, by the way?

RE: Why Flash access should be restricted in radio operation?

jorbar — Thu, 07 Jan 2016 13:18:19 GMT

ok thanks...

But the description of NVMC chapter says that CPU is halted when CPU tries to fetch the CODE/DATA from flash only. that is, if CPU tries to fetch the CODE/DATA from RAM, it says there is no halt.

is it right?

if then, is the flash acccess in radio operation only restricted when CPU is using the flash for fetching CODE/DATA ?

thanks

RE: Why Flash access should be restricted in radio operation?

Vidar Berg — Thu, 07 Jan 2016 12:54:34 GMT

Some processing from the CPU is required to handle the radio events, but not much. The problem with that is that the CPU is halted during flash operations, see NVMC chapter in the reference manual. So the problem is not the radio itself, but the availability of the CPU.