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.

[Einar Thorsrud]

No, writing to flash on the dongle and DK is the same. It is the same IC after all.

[brianreinhold]

Then I am at a loss now to explain why the write to flash crashes the dongle, but the same write on the DK works fine. Any ideas?

Are you sure I am not infringing upon the bootloader?

Here is where I am writing

uint32_t pg_size = NRF_FICR->CODEPAGESIZE;
uint32_t pg_num = NRF_FICR->CODESIZE - 1; // Use last page in flash

uint8_t *addr = (uint8_t *)(pg_size * pg_num);

According to NFR Connect the bootloader is at 0xE0000 to 0xFDFFF

[Einar Thorsrud]

Hi,

brianreinhold said:

Are you sure I am not infringing upon the bootloader?

No. I did not see which address you write to before, but if you try to write to the last page as indicated here you will definitely get problems. While the bootloader itself does not occupy the last two pages, they are used by the bootloader and MBR. The last page is the bootloader settings page, and the second to last is the MBR parameter storage page (see memory layout). You cannot use these pages for other data.

[brianreinhold]

I tried the next to last page and that didn't work either but I see that too is a bad page. So I will try three pages down. Since the DK doesn't have a bootloader and MBR (at least I don't think so) that is why my code works on the DK.

If this is indeed true, you need to point that out in the documentation. At least in the flash write example which uses the last page as the most difficult part of the flash writing experience I had when first trying to get it to work was finding where to write. I would like to start as close to the start of available flash as possible but as I understand it there is no way to dynamically determine that at build time.

[Einar Thorsrud]

brianreinhold said:

I tried the next to last page and that didn't work either but I see that too is a bad page.

Yes, that is the MBR parameters page.

brianreinhold said:

Since the DK doesn't have a bootloader and MBR (at least I don't think so) that is why my code works on the DK.

Yes.

brianreinhold said:

If this is indeed true, you need to point that out in the documentation.

It is described in the bootloader memory layout.

brianreinhold said:

At least in the flash write example which uses the last page as the most difficult part of the flash writing experience I had when first trying to get it to work was finding where to write.

I see your point. However, the example does not support the dongle out of the box, and it is not listed as a supported board. I do not think it makes sense to describe all unsupported board with all examples. That would be a large task and would clutter the documentation with mostly irrelevant information.

brianreinhold said:

I would like to start as close to the start of available flash as possible but as I understand it there is no way to dynamically determine that at build time.

That is correct. Or rather, it would be possible if you adapt the project to the target board (so that the start address is above MBR or SoftDevice (depending on which is relevant), and end address is below the bootloader. But as most examples does not do this for the dongle it will be up to you.