This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

bootloader interferes with application

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

  • 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

  • Thanks Vidar,

                           I reviewed my changes to the default Nordic code this morning. I found three issues:

    1) I was attempting to log before logging was initialised which was causing a hang

    2) I was attempting to use FDS to pass information between the application and the bootloader service. This code just didn't work.

    3) The timeout as you suggested causes a crash when put to 10minutes.

    Is there a preferred way to pass information between the application and the dfu service?

    Cheers 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

  • 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

  • 2) if it's just the device ID (assuming it never changes) I would suggest that you store it at a fixed address, one of the available UICR registers for instance. Then it's easy to reference the device ID from both the app and bootloader using a hardcoded pointer. E.g.,

    DEVICE_ID  NRF_UICR->CUSTOMER[10]

Related