Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Einar Thorsrud — Tue, 24 Oct 2023 13:21:56 GMT

Hi,

Sorry about that, you are right. I but forgot about one important detail. A failed CRC check is ignored. This comes from section in components/libraries/bootloader/dfu/nrf_dfu_validation.c:

            if (crc != current_crc)
            {
                // CRC does not match with what is stored.
                NRF_LOG_DEBUG("CRC check of app failed. Return %d", NRF_DFU_DEBUG);
                return NRF_DFU_DEBUG;
            }

So if NRF_DFU_DEBUG is rue, which it will be when NRF_DFU_DEBUG_VERSION is defined, the app is considered valid even if the CRC does not match.

Note that even if you use the debug version, the settings page needs to indicate that a valid app is present (which it does after generating and programming the settings page or performing a DFU operation). If you do as I suggested initially and modify app_is_valid() you will not need this either.

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Salmat — Tue, 24 Oct 2023 12:34:32 GMT

"blinky.hex" and "hrs.hex" are not the same file at all !

You do not seem to believe me. Just do it yourself on any kit

When I say DO NOT WORK, it goes in DFU.
WORKS it is the application

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Einar Thorsrud — Tue, 24 Oct 2023 12:27:10 GMT

Hi,

Thanks for the explanation. Now I understand what you are doing.

[quote user="salmat"]nrfjprog -f nrf52 --program hrs.hex --sectorerase --reset
WORKS (you said it should not)[/quote]

Have you changed the application in this case or are you programming the same file? If it is the same file, the CRC have not changed, and this will work. But if you do a change and re-build, this will not work as the CRC will not match and the bootloader will enter DFU mode instead of jumping to the seemingly corrupt application.

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Salmat — Tue, 24 Oct 2023 12:16:37 GMT

I have done using settings files as you proposed. It works the same as it did with zip pkg.

extract SDK 17.1.0 downloaded zip

in \external\micro-ecc
git clone https://github.com/kmackay/micro-ecc.git
make

Make all :
\examples\dfu\secure_bootloader\pca10056_s140_ble\armgcc
\examples\dfu\secure_bootloader\pca10056_s140_ble_debug\armgcc
\examples\ble_peripheral\ble_app_blinky\pca10056\s140\armgcc
\examples\ble_peripheral\ble_app_hrs\pca10056\s140\armgcc

rename hex files : bootloader, bootloader_debug, blinky, hrs

Move in a directory, and go in it.
./nrfutil settings generate --family NRF52840 --application blinky.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 --key-file private.key blinky_settings.hex
./nrfutil settings generate --family NRF52840 --application hrs.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 --key-file private.key hrs_settings.hex

We have all files.

With bootloader_debug :
nrfjprog -f nrf52 --eraseall
nrfjprog -f nrf52 --program s140_nrf52_7.2.0_softdevice.hex
nrfjprog -f nrf52 --program bootloader_debug.hex
nrfjprog -f nrf52 --program blinky_settings.hex
nrfjprog -f nrf52 --program blinky.hex
nrfjprog -f nrf52 --reset
WORKS (it is normal)

nrfjprog -f nrf52 --program hrs.hex --sectorerase --reset
WORKS (you said it should not)

With normal bootloader :
nrfjprog -f nrf52 --eraseall
nrfjprog -f nrf52 --program s140_nrf52_7.2.0_softdevice.hex --sectorerase
nrfjprog -f nrf52 --program bootloader.hex --sectorerase
nrfjprog -f nrf52 --program blinky_settings.hex --sectorerase
nrfjprog -f nrf52 --program blinky.hex --sectorerase
nrfjprog -f nrf52 --reset
WORKS (it is normal)

nrfjprog -f nrf52 --program hrs.hex --sectorerase --reset
DO NOT WORK

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Einar Thorsrud — Tue, 24 Oct 2023 06:49:19 GMT

Then I must be misunderstanding what you are doing or what you are seeing/expecting. Can you elaborate in more detailed steps?

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Salmat — Mon, 23 Oct 2023 15:01:31 GMT

No just extracted the zip of SDK, and added micro-ecc (easy to reproduce)

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Einar Thorsrud — Mon, 23 Oct 2023 14:57:15 GMT

That is odd, the integrity check before starting an application is always there by default. Did you inherit the project from someone so that perhaps they have made a change in the SDK code?

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Salmat — Mon, 23 Oct 2023 14:47:46 GMT

Hi,

OK. I did not know how to generate the setting page, thanks ! (it can be a way to solve the problem)

But, as I said, with debug version, I do not have any problem to modify application.
I just tried again with this time SDK 17.1.0, without any modifications, I can modify the application.

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Einar Thorsrud — Mon, 23 Oct 2023 12:02:42 GMT

Hi,

The default behavior of the bootloader is to perform an integrity check of the application before booting it. If the application is not valid, it will enter DFU mode instead. This is the same with debug and non-debug versions though, but it is something that can cause irritation during development as you will have to generate and program a new bootloader settings page in order for the bootloader to flash the new app you have just uploaded via SWD (for instance for debugging).

In order to avoid this you can eider test your application without a bootloader present, live with generating and programming the settings page every time, or disable the integrity check at boot. If you just use this when debugging, you could modify the bootloader so that it skips checks altogether by making app_is_valid() in components/libraries/bootloader/nrf_bootloader.c always return true (if you like, you can make it so that only happens when NRF_DFU_DEBUG_VERSION is set). Make sure you don't go to production with this change though, it should only be used for debugging.

RE: Bootloader : Different behavior between pca10056_s140_ble_debug and Non debug

Salmat — Fri, 20 Oct 2023 19:32:39 GMT

I have find ... it is the NRF_DFU_DEBUG_VERSION parameter defined in "debug" makefile

But I have the feeling NRF_BL_APP_SIGNATURE_CHECK_REQUIRED can not be disabled when NRF_DFU_DEBUG_VERSION is set ?