bootloader interferes with application

[paul]

Hi,

      we have a custom board running the nrf52840. The code is getting pretty good we are getting close to beta. We are using SES as our development platform and are currently using SDK15.0. 

We have implemented three things:

1) our custom ble services etc

2) your example bootloader code

3) your example dfu service

We are finding that if the bootloader and dfu service are flashed to the device, SES tends not to return to debug mode when building and running our custom services by pressing the SES green arrow button.

The secure bootloader and dfu code have been very lightly touched:

1) changed the advertising name using the sdk_config entry

2) updated the key used to encrypt updates

3) updated the dfu timeout to 10 minutes

4) added code to read the device id from fds

the ?hang? was occuring intermittently after the first two changes and all the time after the last two. I assume that there is some form of flash conflict on write - on overwriting the other or something - but have no idea how to progress trouble shooting. During the ?hang? it doesn't appear to advertise which is about the first thing our code does.

The softdevice is installed as an additional load file in the loader pane of the project options. The bootloader etc is installed by running the following script as a user build step:

#!/bin/bash

BOOTDIR="/home/paulc/dev/2flex_nrf52/bootloader"
LOADERFILE="secure_bootloader_ble_s140_pca10056_debug.hex"
LOADERLOC="../sdk/examples/dfu/secure_bootloader/pca10056_ble_debug/ses/Output/Release/Exe/${LOADERFILE}"
APPLOC="/home/paulc/dev/2flex_nrf52/Output/Debug/Exe/2flex_nrf52.hex"
SETTINGSFILE="bootloader_setting.hex"
FLASHFILE="payload.hex"
NRFUTIL="/usr/local/bin/nrfutil"
MERGEHEX="/home/paulc/dev/2flex_nrf52/mergehex/mergehex"
NRFJPROG="/home/paulc/dev/2flex_nrf52/nrfjprog/nrfjprog"

pushd ${BOOTDIR}
cp ${LOADERLOC} .
echo "Generating the bootloader settings"
${NRFUTIL} settings generate --family NRF52840 --application ${APPLOC} --application-version 0 --bootloader-version 0 --bl-settings-version 1 ${SETTINGSFILE} --no-backup
echo "merging with the bootloader"
${MERGEHEX} --merge ${LOADERFILE} ${SETTINGSFILE} --output ${FLASHFILE}
echo "programming the bootloader onto the chip"
${NRFJPROG} -f NRF52 --program ${FLASHFILE} --chiperase
popd

A typical run look like:

./prog_bootloader.sh
~/dev/2flex_nrf52/bootloader ~/dev/2flex_nrf52
Generating the bootloader settings

Generated Bootloader DFU settings .hex file and stored it in: bootloader_setting.hex

Bootloader DFU Settings:
* File:                     bootloader_setting.hex
* Family:                   NRF52840
* Start Address:            0x000FF000
* CRC:                      0x6A257EB5
* Settings Version:         0x00000001 (1)
* App Version:              0x00000000 (0)
* Bootloader Version:       0x00000000 (0)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x0002A5E8 (173544 bytes)
* Application CRC:          0x94916576
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x00000000
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000000 (0)

merging with the bootloader
Parsing input hex files.
Merging files.
Storing merged file.
programming the bootloader onto the chip
Parsing hex file.
Erasing user available code and UICR flash areas.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
~/dev/2flex_nrf52

Many thanks in advance

Paul

[Vidar Berg]

Hi Paul,

Please try to change the timeout back to 2 minutes to see if that helps. I remember we had an issue where we didn't handle timer overflow (RTC), but not sure if it has been fixed in SDK 15.0.0. I will add more details once I have had time to look at the code in more detail. 

Best regards,

Vidar

[paul]

Vidar,

          even with the 120 sec timeout I still get an intermittent failure to load the application when the bootloader is present. The solution is to use SES to erase all, run the bootloader flash script and then run the application. Usually this starts it working again. This is why I am thinking that there is some corruption somewhere.

Cheers Paul

[Vidar Berg]

Paul, 

Thanks for the update. Just so I understand the issue correctly, Is this the failure mode: "ES tends not to return to debug mode when building and running our custom services by pressing the SES green arrow button"? On boot, the bootloader will always calculate the CRC of the app image and check that it matches the "Application CRC" stored in the settings page. If there's a CRC mismatch the bootloader will think that the app is invalid and fall back do DFU mode. Could this be the reason?

Cheers 

Vidar

[paul]

Hi Vidal,

               Yes that is a good description of the error case I am seeing. Interesting suggestion about the bootloader CRC. I have been thinking about it all day. 

1) The application is changing all the time so I would expect it to practically never run if it was a crc issue.

2) I don't think that the update service (DFUTarg) is displayed in the error condition.

3) The best way I have found to flash the boot loader is to run the script above by hand and then enter SES and use it to down load the application. So the bootloader - unless SES tells it about the application - knows nothing about the application. If SES does tell it - maybe store the crc somewhere - then it should always work.

If I totally misunderstand, how do I get SES to update the crc on each compile and download to the device?

Thanks again

Paul

[Vidar Berg]

Hi Paul,

1. Assume you update the bl settings page through nrfutil when you change the application? Otherwise, the bootloader should not boot the application as the CRC has to be different.

2. That's a symptom of a different problem. The device will be advertising with a different BLE address when in DFU mode (regular address + 1). Could this explain why you don't see the device? I.e., you try to connect to the device with the "normal" address. 

3. SES uploads the .elf file when programming the app while nrfutil uses the .hex file to calculate the CRC. Both will result in the same code being uploaded to flash. However, they may have different byte padding rules causing the calculated CRC of the app image in flash to be different from the CRC generated by nrfutil in the bootloader settings page. I had a case on this earlier but wasn't able to find it now. But as a test, can you try to disable the CRC check in the bootloader to see if the problems go away?

To disable crc check you can modify this line in nrf_bootloader.c::crc_on_valid_app_required():

static bool crc_on_valid_app_required(void)
{
    //bool ret = true;
    bool ret = false; // <-- always return false. Revert this change for production FW
    if (NRF_BL_APP_CRC_CHECK_SKIPPED_ON_SYSTEMOFF_RESET &&
        (nrf_power_resetreas_get() & NRF_POWER_RESETREAS_OFF_MASK))
    {
        nrf_power_resetreas_clear(NRF_POWER_RESETREAS_OFF_MASK);
        ret = false;
    }
    else if (NRF_BL_APP_CRC_CHECK_SKIPPED_ON_GPREGRET2 &&
            (nrf_power_gpregret2_get() & BOOTLOADER_DFU_SKIP_CRC))
    {
        nrf_power_gpregret2_set(nrf_power_gpregret2_get() & ~BOOTLOADER_DFU_SKIP_CRC);
        ret = false;
    }
    else
    {
    }

    return ret;
}

Vidar

[paul]

Hi Vidar,

               many thanks for your help. Turning off crc checking as you describe appears to have solved the hang. I will be looking into the UICR registers to pass information between the bootloader and the app.

Cheers Paul