Fstorage - fs_erase causes connection failure

[John]

Hello,

I'm encountering a very strange problem while attempting to run an fstorage fs_erase operation on my peripheral device when the central is connected. This is on a nRF52832, SDK 12.1.0, SoftDevice S132 v3.0.0 and running FreeRTOS. The peripheral stores configuration and logged data in program flash space using fstoreage.

Basically what happens is that the central device connects to my peripheral in order to configure it. One of the steps the peripheral must do is erase a configuration page. When the peripheral invokes fs_erase, the connection drops. I added debug and I can see that the fs_erase command and completion event take less than ~200mS to occur. However the connection is dropping due to a connection supervisor timeout. I've tried this with the default time out of 720mS, and with the connection supervisor timeout negotiated up to 6,000mS. It fails in both cases.

I watched what happens in the sniffer, and I see the command received by the peripheral. Then when the peripheral starts the erase process, it stops responding to the connection events from the central with the expected empty packets. The lack of response continues until the connection supervisor timer pops.

Some other notes:

1. If I invoke the erase from our Serial Uart CLI rather than OTA, the connection drops in the exact same fashion.

2. The fstorage configuration looks correct when compared to another project in the same environment where this doesn't occur.

3. The command from the host is initially handled in interrupt context, but the command is passed to our command processing user level task for processing before the fs_erase is invoked.

4. We are reserving 34 pages of program flash: 32 for data, 1 for a passkey, and 1 for recording user information. It doesn't matter which page we erase, the problem occurs.

5. We have another project with nearly the exact same setup (it's where I got the code from!) and it does not have this behavior. You see a few connection events ignored, but it's only for tens of milli-seconds.

What could I be doing wrong that the stack would return a NRF_EVT_FLASH_OPERATION_SUCCESS event to us, but not resume normal operations with the host?

I can post code if needed, but I didn't want to bloat the question further unless it would be helpful

Thanks, John

[Petter Myhre]

Very strange indeed. Are you sure you are not calling APP_ERROR_CHECK() with an error code somewhere and you get a reset? What happens after you get NRF_EVT_FLASH_OPERATION_SUCCESS? Are you getting further in your program?

[John]

Hi Petter,

Yep, I was sure that I was not getting a reset. The board kept executing normally as my CLI did not show a reset and that's pretty obvious since the welcome banner prints and you get a prompt of "00:00:00>".

That said, I worked with this over the weekend. I was forced to conclude on Saturday after trying many things that perhaps the connection interval timings were too tight. So on Sunday I loosened them up and that forced a connection parameters negotiation near the start of the connection. Once the negotiation completed, I observed a similar behavior. No response to connection events until after the connection supervisor popped.

This of course was a bit puzzling because I've seen plenty of successful parameter negotiations with this software, and never seen this before. Plus these were very vanilla connection settings. This got me to be very suspicious of the development board I was trying to bring up. So, it was off to the lab and the magnifiers. It became pretty clear quickly what was likely wrong. The entire top of the 32KHz Oscillator was missing! No idea why, perhaps some crazy experiment by the HW guys, who knows. Replaced with another development board, and the connection settings did seem to fix the flash erase problem. Further experimentation with the parameters will go on this week to make sure that with the original connection settings that we aren't on the edge of having flash operations issue. I know you guys have a table about that in the manual, but I'll be a lot more comfortable after some testing to go with that.

[Petter Myhre]

I see :) Thanks for the update!