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

pstorage_update failing about 5% of calls

I'm working on an application that uses the persistent storage manager to store some calibration data. I thought I had everything working well, but after higher volume testing, I found that the calls to pstorage_update are failing about 5% of the time.

I'm using SDK 6.1 and S110 7.3.0. I don't want to update the SDK this late in the process, and we have hardware with older rev chips that we need to support, but if there are any known bugs in 6.1 or patches, that would be good to know. I haven't found any specific errata yet.

Normally when I call pstorage_update, my callback is called with the PSTORAGE_UPDATE_OP_CODE.

When this problem occurs, the callback is just not called. In testing I have tried calling pstorage_update again, and typically this results in both operations completing. I then get two calls to the callback with PSTORAGE_UPDATE_OP_CODE. I haven't tried to figure out what order they are completing in (both calls are the same). Sometimes, I have to call update a 3rd time, and then I get three callbacks. Obviously, the updates are getting queued but never executed, and the second or third call "kicks" things back into normal operation.

Here's what I've tried so far:

  1. My calls to pstorage_update were originally from within a callback in interrupt context. Several questions here address this, and I am now using the app_scheduler so that everything is called from the main loop.

  2. I have tried disabling advertising to see if radio activity is the issue. I still have the same symptoms.

  3. I have an app_timer that fires periodically at 50 ms. Is it possible that this would interfere with pstorage? At any rate, I've also tried stopping that.

  4. If I perform minimal initialization and then do the write repeatedly from within the main loop, it seems to work 100% of the time, so I know I have some kind of conflict. This is with no app_timers or advertising.

So, a few basic questions:

  1. Is the radio the only thing that should interfere with pstorage executing successfully?
  2. Is it possible that a frequent app_timer with a lengthy handler, called with the app_scheduler, could interfere with pstorage?
  3. Is not getting the pstorage callback at all a normal failure mode?
  4. Would high priority interrupts, like gpiote interfere? (just a theoretical question)

Thanks, Philip

Parents
  • The problem turned out to be the same as this post: <a devzone.nordicsemi.com/.../>

    It doesn't have anything to do with the timer directly, but my battery voltage measurement function doesn't get called with the timer stopped, and it's the battery measurement/ADC that was generating NRF_EVT_HFCLKSTARTED events sent to pstorage_sys_event_handler()

    The question I linked to was reported in 2014, and it doesn't look this bug has been fixed in SDK9.0. The event handler still unconditionally clears m_cmd_queue.flash_access if the function is called with an event unrelated to pstorage, so I fixed it by checking the event type in my main event handler.

Reply
  • The problem turned out to be the same as this post: <a devzone.nordicsemi.com/.../>

    It doesn't have anything to do with the timer directly, but my battery voltage measurement function doesn't get called with the timer stopped, and it's the battery measurement/ADC that was generating NRF_EVT_HFCLKSTARTED events sent to pstorage_sys_event_handler()

    The question I linked to was reported in 2014, and it doesn't look this bug has been fixed in SDK9.0. The event handler still unconditionally clears m_cmd_queue.flash_access if the function is called with an event unrelated to pstorage, so I fixed it by checking the event type in my main event handler.

Children
Related