SDK 14 migration: can't advertise. fstorage busy.

RE: SDK 14 migration: can't advertise. fstorage busy.

Eliot Stock — Fri, 18 Aug 2017 14:20:27 GMT

So this was, quite frustratingly, just down to a missing define in my app_config.h (like sdk_config.h, but partial, and applied over the top).

It turns out it's entirely possible to build an app in which NRF_SDH_SOC_ENABLED is not defined or is 0 and therefore there are no SoC events going out to observers at runtime. You won't know it's not happening, even if you've got the BLE advertising module set up properly. I'd have expected the app not to link, but it does.

RE: SDK 14 migration: can't advertise. fstorage busy.

Eliot Stock — Fri, 18 Aug 2017 10:49:02 GMT

I guess you mean nrf_sdh_soc_evts_poll() in nrf_sdh_soc.c. Will take a look.

RE: SDK 14 migration: can't advertise. fstorage busy.

Eliot Stock — Fri, 18 Aug 2017 10:43:02 GMT

I see what you mean. BLE_ADVERTISING_DEF() calls NRF_SDH_SOC_OBSERVER() and passes it the ble_advertising_on_sys_evt() handler. I have all the sections in my linker script as per the HRS example, including the one for sdh_soc_observers. What poll loop? Where is that?

RE: SDK 14 migration: can't advertise. fstorage busy.

RK — Fri, 18 Aug 2017 10:32:07 GMT

yes that's it - theres an sdh_ble_observers section, things put in there are iterated when you poll and dispatched to. So just go back to the poll loop and work out whether you're getting FLASH events or not.

Before BLE starts up, working out what's going on with a debugger is pretty simple and at this point, BLE hasn't started up.

RE: SDK 14 migration: can't advertise. fstorage busy.

RK — Fri, 18 Aug 2017 10:27:06 GMT

well I see some macros NRF_SDH_BLE_OBSERVER which seem at first glance to set up static data which the ble system reads and adds handlers. That uses those blasted sections which are fine in keil but a total pain in the ass in SES and other IDEs and require you to go fix the linker scripts in 10 places.

So my guess is that's where it's set up.

The SDK has become a bit too clever for its own good and now tries to save you from yourself having to remember to register things, net result, the code is magical and when it doesn't do what you expect, it's nigh on impossible to figure out why.

hat's my guess anyway.

RE: SDK 14 migration: can't advertise. fstorage busy.

RK — Fri, 18 Aug 2017 10:17:31 GMT

also it seems rather suspicious that the peer manager (or rather the fds subsystem) decides every time you run it that it's not initialized and goes and writes. You'd think it would happen once (or once each time you wiped the chip) and then next time through it would decide it's initialized and return early without a write. So that makes it seem as if the writes aren't completing or aren't being scheduled, which may then be why they aren't triggering the advertising module to restart. eg for instance the fds system doesn't see the write event, so it never marks itself as 'ok', the advertising module does see it but thinks fds is still busy and doesn't start.

That would also happen if the advertising module gets the event BEFORE the fds system sees it. It would try to restart, the fds system is still busy. Doesn't explain why it re-inits every time. Should be able to trace thru that.

RE: SDK 14 migration: can't advertise. fstorage busy.

Eliot Stock — Fri, 18 Aug 2017 10:16:40 GMT

Yes of course, a breakpoint in ble_advertising_on_sys_evt() is never hit. I can't see how that function is set up as a handler, since there are no references to it anywhere else in the SDK that I can find. If I knew that, I wouldn't be asking the question.

RE: SDK 14 migration: can't advertise. fstorage busy.

RK — Fri, 18 Aug 2017 10:09:15 GMT

I don't understand your questions sometimes. You have the whole stack trace, you have all the source code, you can see that write() is supposed to be happening there by just looking quickly through the function. If you're at line 1639 you went past the 'already init' stage and so fds has queued up operations.

As to why the advertising manager doesn't pick up again .. well have you put a breakpoint in that routine, is it ever called? Probably not. So either it's not hooked up, or the event isn't ever being generated (which would be bad) or you're not getting to the event loop processing code and dequeueing them.

RE: SDK 14 migration: can't advertise. fstorage busy.

Eliot Stock — Fri, 18 Aug 2017 10:08:38 GMT

@RK Thanks. Confirmed it's the peer manager doing a write. See edit above.

RE: SDK 14 migration: can't advertise. fstorage busy.

RK — Tue, 15 Aug 2017 21:13:18 GMT

and does initializing the peer manager cause it to queue up and start an fstorage operation as the first thing it does? Should be quite easy to pop a breakpoint on the code which increments the queue count on that fstorage SD module and see the stack trace where it's called. Sounds legit to me. The other part of the original question about whether the right things are hooked into the event stream is more interesting, however I don't really have any insight not having done any work (sadly) with recent SDKs or softdevices.

RE: SDK 14 migration: can't advertise. fstorage busy.

Eliot Stock — Tue, 15 Aug 2017 15:09:58 GMT

No, it's a custom app that uses a custom service, based on the HRS and buttonless DFU bootloader examples. I checked and it looks like the peer manager is the only user of the fstorage module. I init that before I start to advertise of course.

RE: SDK 14 migration: can't advertise. fstorage busy.

Petter Myhre — Tue, 15 Aug 2017 13:49:20 GMT

Are you saying you are experiencing this with the unmodified HRS example from SDK 14.0.0?

If is_busy() returns true I guess m_queue.cnt !=0. Could you check?

static bool is_busy(nrf_fstorage_t const * p_fs)
{
    return (m_queue.cnt != 0);
}

RE: SDK 14 migration: can't advertise. fstorage busy.

Eliot Stock — Tue, 15 Aug 2017 09:02:18 GMT

Thanks, good point. Have done that and added an edit above, but I'm not sure what it tells me. Not sure how to see the module using the fstorage instance from this.

RE: SDK 14 migration: can't advertise. fstorage busy.

RK — Mon, 14 Aug 2017 20:48:48 GMT

The first part can't be too hard to work out - just single step the busy function to find out which of the registered fstorage modules is returning true. Since you've not even started advertising, you can single step to your hearts content. There's probably only one such module registered and a couple of breakpoints should quickly show where it's being used.