Bug in how bootloader treats GPREGRET

RE: Bug in how bootloader treats GPREGRET

ziv123 — Sun, 13 Jun 2021 05:50:44 GMT

thanks 🙂

RE: Bug in how bootloader treats GPREGRET

tesc — Fri, 11 Jun 2021 07:16:38 GMT

Hi,

The POWER peripheral is restricted when the SoftDevice is enabled, so then you must use the SoftDevice API instead of accessing the registers directly.

For setting GPREGRET, see sd_power_gpregret_set().

Regards,
Terje

RE: Bug in how bootloader treats GPREGRET

ziv123 — Thu, 10 Jun 2021 12:59:03 GMT

hi David

regardless of the bootloader issue entering DFU mode, in my application, when i use this command:

NRF_POWER->GPREGRET = 0xB1;

i get asserted,

any idea why ?

best regards

Ziv

RE: Bug in how bootloader treats GPREGRET

Pete W — Sun, 01 Nov 2020 16:36:07 GMT

Ah, I get it now.

RE: Bug in how bootloader treats GPREGRET

Pete W — Sun, 01 Nov 2020 16:08:05 GMT

Caught me out as well.

Surely it should just simply use the start bit mask (0x01), i.e.

if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
(nrf_power_gpregret_get() & BOOTLOADER_DFU_START_BIT_MASK)
{
NRF_LOG_DEBUG("DFU mode requested via GPREGRET.");
return true;
}

RE: Bug in how bootloader treats GPREGRET

tesc — Mon, 28 Sep 2020 14:06:45 GMT

Hi,

+1 noted.

Can be fixed by changing nrf_bootloader.c lines 377-382:

    if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
       (nrf_power_gpregret_get() & BOOTLOADER_DFU_START))
    {
        NRF_LOG_DEBUG("DFU mode requested via GPREGRET.");
        return true;
    }

To this:

    if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
       (nrf_power_gpregret_get() & BOOTLOADER_DFU_GPREGRET_MASK) == BOOTLOADER_DFU_GPREGRET)
            && (nrf_power_gpregret_get() & BOOTLOADER_DFU_START_BIT_MASK))
    {
        NRF_LOG_DEBUG("DFU mode requested via GPREGRET.");
        return true;
    }

Regards,
Terje

RE: Bug in how bootloader treats GPREGRET

David Meiklejohn — Fri, 25 Sep 2020 06:53:53 GMT

Just a '+1' on this: I'm a bit annoyed that I spent half an afternoon debugging what I thought was an error in my code, to find that my bootloader was incorrectly entering DFU mode due to this bug.

I do understand that bugs happen - just a bit concerned that this was first reported more than 2 years ago, and still persists in SDK17, even though it's really easy to fix.

I'll need to make my own custom copy of nrfbootloader.c to fix this. Oh well...

RE: Bug in how bootloader treats GPREGRET

tesc — Fri, 21 Aug 2020 16:46:03 GMT

Hi,

You are entirely correct. In this location, the same approach to testing magic word + signal should be used as is correctly done in crc_on_valid_app_required() and in dfu_enter_flags_clear() in the same file. I have notified the SDK team.

Thank you for the reports.

Regards,
Terje

RE: Bug in how bootloader treats GPREGRET

Richard D. — Thu, 20 Aug 2020 00:08:31 GMT

The bug still exists in SDK 17.0.

nrf_bootloader.c, line #377

if (NRF_BL_DFU_ENTER_METHOD_GPREGRET &&
(nrf_power_gpregret_get() & BOOTLOADER_DFU_START))

RE: Bug in how bootloader treats GPREGRET

Phil — Fri, 08 Nov 2019 20:51:59 GMT

We are using SDKv15.3.0 and I found this error accidentally.

We wanted to put a value in GPREGRET that the bootloader would ignore so the application would run and read the GPREGRET register and restore an operating mode that was active before reset.

We found that almost any combination of bits GPREGRET caused the device to enter boot-mode after reset, but could only exit after a power off/on. I found the fault due to the bitmask operation, and corrected it as described above.

If we had deployed this code on on devices in the field it would have been impossible to cause them to exit boot-loader mode once the value in GPREGET doesn't have the bits set according to the bitmask. We deploy hundreds of devices in remote sites. This would have been a major problem for us.

This is a typical case where it works correctly when tested in the way it's supposed to work. Clearly this was never tested with combinations of bits other that what is specified to get into and out of boot-loader mode.

This is such an amateurish error.

If the boot-loader source code wasn't available, we would not have been able to fix it

RE: Bug in how bootloader treats GPREGRET

tesc — Fri, 08 Nov 2019 11:58:08 GMT

Hi,

Yes. This was fixed prior to nRF5 SDK v15.3.0. It is not an issue for v15.3.0 and newer.

Regards,
Terje

RE: Bug in how bootloader treats GPREGRET

Steven Jian — Fri, 08 Nov 2019 02:39:18 GMT

Have you fix this issue?

RE: Bug in how bootloader treats GPREGRET

tesc — Thu, 25 Oct 2018 11:28:42 GMT

Hi,

Thank you for the feedback! Agreed, and noted. Your points have been forwarded to the SDK team. We do take testing seriously, and any feedback, also on test coverage, is appreciated.

Regards,
Terje

RE: Bug in how bootloader treats GPREGRET

DerPMO — Thu, 25 Oct 2018 10:03:18 GMT

This is a SERIOUS Problem! We've just stumbled on this by ourselves and you confirmed it here. To be honest, this kind of destroys my trust in the bootloader and the SDK because it seems like a basic lack of understanding binary operators.

Also, I expect that you do at least some sort of testing of such features and if you do, there is a major part missing:

In this case I suspect the devs checked that the correct magic byte indeed does trigger the DFU, and maybe even if 0x00 doesn't trigger it. But apparently nobody ever checked if any other byte could trigger this as well! I can only hope that Nordic recognizes this problem and adds something to the standard testing definitions to also check for "false positives" not only true positives and false negatives!

RE: Bug in how bootloader treats GPREGRET

tesc — Tue, 04 Sep 2018 18:21:15 GMT

Hi,

I am sorry for the delay. Thank you very much, bug reports of this nature are always appreciated!

Looking into the matter I agree this is very likely to be a bug. Just as you write, the comments on the defines implies that there is a five bit magic pattern to signal it is a message from a buttonless DFU service to the DFU bootloader, and a three bit signal. But in dfu_enter_check, setting any of bits 7, 5, 4 or 0 will trigger DFU mode. This must be wrong.

I have updated the feature request that was registered based on the other thread, and it is now a bug report including your observations and my own. Hopefully it will be fixed before too long.

Regards,
Terje