sd_softdevice_is_enabled returns false but then nrf_sdh_enable_request() returns error 8 = softdevice already enabled

[brianreinhold]

Have a catch-22 here.

Here is my code:

    sd_softdevice_is_enabled(&enabled); // Don't do this if disabled, for example when writing flash at the end
    if (enabled != 1)
    {
        bsp_board_led_on(ERROR_LED);
        result = nrf_sdh_enable_request();
        if (result != NRF_SUCCESS)
        {
            NRF_LOG_ERROR("Re-enabling the soft device failed with code %u", result);
            NRF_LOG_DEBUG("Restarting application");
            while(NRF_LOG_PROCESS());
            NVIC_SystemReset();
            return;
        }
        NRF_LOG_DEBUG("No reset was done! Now what?");
    }

When I call nrf_sdh_enable_request() it returns the error '0x08 which is SoftDevice already enabled according to the documentation. Now I have disabled softdevice to do a flash write.

THe code may seem a little funky but I am dealing with another problem - on the DK the NVIC_SystemReset(); works but when running on the nRF52840 dongle it does not. So I am trying to work around the bug by re-enabling softdevice and restarting advertising. But that's another one of several issues I am having. Now this one.

Is the error message bad and it is really something else?

NOTE READERS LOOKING AT THIS PROBLEM. The problems I was having ended up being due to the flash write on the dongle versus the DK. That is what made it look like the reset was not working on the dongle. SO I was diving into work a rounds for that. It led to a great number of red herrings. If you follow through this thread it ends up finally focusing on the flash write -  not the issue in the title. Some of the other issues raised here are not answered as they were no longer pursued.

[brianreinhold]

I understand that the dongle is not for debugging, that's what the DK is for. But I am trapped in a corner case where the DK works and the dongle does not. I also have a case where I can't get the DK's buttons to work. The two may be related. So I need to fix the buttons first before I can play with blinkys.

By the way, does that nrf_delay() tag the CPU or put the caller in a 'sleep'. This is a question I have asked before without a clear answer. For example could I make a call that is asynchronous, make this nrf_delay() call and then check some volatile to see if an event were triggered during the delay or would it simply deadlock the entire system such that the event would not be signaled?

Another question: Maybe I have to do something extra in SES and Keil to generate a HEX file to install on the dongle? The HEX file generated by SES at least runs, even though it dies on the NVIC_SystemReset(). But the HEX file generated by Keil doesn't even start. Then I noted in Keil under the Utilities there is a 'Use External Tool For Flash Programming' option. I did not check that but do I need to check that in order to use NRF Connect to flash the dongle with the Keil-generated HEX file?

[Einar Thorsrud]

Hi,

brianreinhold said:

does that nrf_delay() tag the CPU or put the caller in a 'sleep'

nrf_delay_* does not put the CPU to sleep. (On the nRF52840 and recent SDK versions it is implemented using the Data Watchpoint and Trace to get exact timing. On devices without a DWT unit and older SDK versions it simply uses a loop and iterates as many times as required in order to consume the specified amount of time.) It does not block interrupts in itself, but as it is busy waiting, it will block interrupts of same and lower priority (so say if you use it in an interrupt/event handler, only higher priority interrupts will be able to run).

Note that nrf_delay is typically not something you want to use in production code (as busy waiting prevents CPU from doing other tasks or sleeping), but it is often nice to have for simple testing etc.

[brianreinhold]

Okay, that's what I thought. Now back to the central theme. If I do that wiring will I be able to use putty to get log output when running the dongle like I do when running the DK? That's really the only option I have to debug - lots of log messages. Line by line debugging dies because of the timing issues of Bluetooth and the event loop in my 'mainLoop()' (This is where I handle events from the sd_app_evt_wait() method.) The mainLoop also detects when soft device has been disabled and that's when it does a reset.

SoftDevice is disabled to do flash writes after a disconnect. The alternative is to keep softdevice alive but then I need to invoke another event handler in my mainLoop() since the flash write is asynchronous. Handling that will make the code so messy and complicated for a rare event. I want that main loop to be as efficient as possible as it handles Bluetooth notification fragmentation. Again that loop is central as it is the only way to handle asynchronous events, for example when you run out of TX buffers on your notification fragmentations. It is a surrogate for the lack of a wait on a semaphore feature (where the wait is a sleep and not a busy loop).

[Einar Thorsrud]

Hi,

brianreinhold said:

If I do that wiring will I be able to use putty to get log output when running the dongle like I do when running the DK?

No. What I described only gives you debugger access. On the DK the debugger acts as a USB-UART bridge, but that is not available on the debug out port. You can of course configure UART logging and use some USB-UART bridge if you like, though. That could also be independent of a debugger, for instance using a FTDI chip or similar. However, with a debugger you can use RTT logging, and the logger module in the SDK is configurable and can use RTT instead of UART as backend. In that case, you will get essentially the same features via the debugger. That is what I recommend in this case.

[brianreinhold]

Being horrible at configuration it will probably take me a year to figure out how to do that, never mind not having the hardware to do any of the mechanical work. I think other things need to be looked at first from my kitchen table. 

What about flash writes? Is there something I need to do special to configure flash writes on the dongle versus the DK?

Doing a quick experiment I commented out all code related to flash reads and writes (start and end of program). If I do not need to do a flash write, I do not do an NVIC reset, I just start re-advertising. That works. No problems, the dongle runs forever.

Now I am going to invoke an NVIC_SystemReset WITHOUT any flash writes

Low and behold that works too. So there is something about the flash writes on the dongle that is different than the flash writes on the DK. On the DK the flash writes work fine - I write in stuff and I get it back when I read. Apparently, on the dongle, the write causes the dongle to crash. Has it got a different memory layout than the DK?

At least it is clear where the problem is. Its not the NVIC_SystemReset()! That now works fine!

I am writing on the last page of flash - like the demo example. Am I overwriting the DFU doing that?