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

PStorage Taking Precisely 10 Minutes to Write or Clear

I have an implementation of pstorage that works very effectively in one build of software, but is dramatically slower in another. Specifically it is taking 10 minutes to actually complete a write or clear operation.

During that time, there are no other significant activities ongoing (a tick timer expires periodically and updates a count of time). Bluetooth is in a disconnected state, not advertising. The UART console is not outputting any text. The device will go to a "wait" state when there are no events... but I've commented out the wait operation with no effect.

The primary difference between the two builds of code is that one lives in a 256K part, and the other in a 128K part. I've done other checks to ensure that things are correct... specifically

  1. Since there are two apps that use pstorage, PSTORAGE_MAX_APPLICATIONS is set to 2.

  2. I believe that in fact 3 blocks not 2, are required at the end of flash to handle this many apps.

  3. I've changed the code space to ensure it ends 3 blocks (precisely at 0x1F400) shy of the end of flash.

  4. there is no bootloader.

  5. the flash block ID that comes back for the first app (device manager) is 0x1F400. The flash id block that comes back for my app is 0x1F800.

  6. Eventually the write does succeed. The value written is read back (ZERO wait for the read operation!!!) precisely as written. It just takes 10 minutes to do the write!

  7. Upon reboot a written value is read back properly (it was stored properly to flash).

Any help at all is most welcome (though please refrain from, "hey why aren't you on the latest release" comments, unless you have specific information regarding fixes between the SDKs/Soft Devices that address this issue).

Stats: Soft Device Version 7.1.0 SDK Version: 6.1.0.

Many Thanks. Steveo

Parents
  • @Rushd: I went back and confirmed that yes, the call to "softdevice_sys_evt_handler_set(sys_evt_dispatch)" is in place and should be called at bootup. Also, the contents of sys_evt_dispatch do issue a pass of the event to pstorage_sys_event_handler. I've also gone and taken a quick look at pstorage.c that I'm linking in from the sdk, and ensured it had a some reasonable content in it. However, you've made me question whether I'm doing things right in general. Because the code works in a different board properly, with no significant code change, I have to believe in general it is correct... but there could be some edge cases, wrt erasure and the like, I haven't considered. I'll revisit this, and look at the below in detail as well, just to get ideas.

    devzone.nordicsemi.com/.../

Reply
  • @Rushd: I went back and confirmed that yes, the call to "softdevice_sys_evt_handler_set(sys_evt_dispatch)" is in place and should be called at bootup. Also, the contents of sys_evt_dispatch do issue a pass of the event to pstorage_sys_event_handler. I've also gone and taken a quick look at pstorage.c that I'm linking in from the sdk, and ensured it had a some reasonable content in it. However, you've made me question whether I'm doing things right in general. Because the code works in a different board properly, with no significant code change, I have to believe in general it is correct... but there could be some edge cases, wrt erasure and the like, I haven't considered. I'll revisit this, and look at the below in detail as well, just to get ideas.

    devzone.nordicsemi.com/.../

Children
No Data
Related