This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Current consumption on flash erase/write and timing

Hello

I'm looking for some information about flash erase/write currents for the nRF52840.

Somewhere here in the forum there where values mentioned about 4mA for flash erase/write of the nRF52832.  Also in this posting it was said that timing should be around minimum specified time (ms range for page erase).

My own measurements show that for the nRF52840 page erase time is around maximum at room temperature.  So what current can I assume?

Note that our application is sensitive concerning peak currents.  Allowed average current is around 1mA.

Thanks

Hardy

Parents
  • Hi,

    In terms of timing to erase or write, you should calculate based on the worst case numbers, so if you need 1mA on average I suspect you will need rather large caps to handle approx. ~4mA for ~90ms, and stay idle for approx ~270ms  before that.

    Best regards,
    Kenneth

  • Other idea to avoid these large capacitors, could be to use the partial erase feature of the nRF52840.  This would allow to split the erase operation into e.g. 10 chunks.  Unfortunately there is no API in the softdevice S140 for this  (Nordic?  Anybody??  Would be great, if this could be added somehow)

  • Hi,

    The datasheet does not contain any electrical data on the flash erase (or write) currents, so 4mA is basically just measurements done on a few DK while doing erase operation.

    The softdevice api does not have any feature that support partial erase no, however if you don't need to erase the flash frequently, you can always disable the softdevice and erase the flash as you see fit, and then enable the softdevice again afterwards.

    Best regards,
    Kenneth

  • Unfortunately this is not feasible: we use the internal flash for persistent configuration data changed via BLE and also for something like file I/O also done via BLE.  So the softdevice should remain switched on.

  • Then I am not sure if I have any good suggestion other than possible an external I2C EEPROM.

  • Thanks Kenneth for your help.  I'm yet not sure how to continue.  I think that Nordic should specify the flash in more detail.  Also a minor extension to the Softdevice flash API would be very helpful.  In fact this partial erase feature could be completely hidden inside.

    Kind regards

    Hardy

  • I see that you've marked one of Kenneth's replies as an answer.

    Some more points to consider:

    • BLE listening times (e.g. if you need to wait for a message response or notification) will likely be more power hungry than flash writes.
    • If you perform bonding then the SoftDevice will write bonding information to internal flash. I don't know if this can be circumvented without looking.
    • An external flash will eat into your power budget and likely not save you anything.
    • For internal flash, data must be erased before the third write of the same 32bit block.
    • Beware of leakage currents and internal resistance with "booster" caps, they will also impose a delay on your start-up.
    • Consider using a low power state with full RAM retention e.g. do you really need flash?
    • Consider storing data in flash in small chunks over an extended period - this will allow you to use smaller "booster" caps and allow for recharge time.
Reply
  • I see that you've marked one of Kenneth's replies as an answer.

    Some more points to consider:

    • BLE listening times (e.g. if you need to wait for a message response or notification) will likely be more power hungry than flash writes.
    • If you perform bonding then the SoftDevice will write bonding information to internal flash. I don't know if this can be circumvented without looking.
    • An external flash will eat into your power budget and likely not save you anything.
    • For internal flash, data must be erased before the third write of the same 32bit block.
    • Beware of leakage currents and internal resistance with "booster" caps, they will also impose a delay on your start-up.
    • Consider using a low power state with full RAM retention e.g. do you really need flash?
    • Consider storing data in flash in small chunks over an extended period - this will allow you to use smaller "booster" caps and allow for recharge time.
Children
  • Hi cbd

    thanks for your suggestions.  Writing to flash is actually not the problem.  Erasing a page is.  And as long as partial erase is not supported by the softdevice I can see no way to get around the 4mA*80ms.

    You are right: an external serial flash is also no option.  There exists a single device which has comparable low erase currents. but this would be another "single source".

    And yes: flash is really required for persistent parameters of the device and also as data storage for an application update.

    Regards Hardy

Related