Why Flash access should be restricted in radio operation?

[jorbar]

Hi

I want to know why flash memory access should be scheduled in between the protocol radio event? is there any relation between the flash access and radio opeartion physically ?

thanks

[Vidar Berg]

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.

[jorbar]

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

[RK]

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?

[jorbar]

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..

[xtting]

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?