Stuck with bootloader sample

[Bruno Miguelez]

Dear Nordic Experts,

We are adding BLE functionality to an existing product so we have replaced its main micro-controller by the nRF52810. Our custom board is now in the fab so we are still working with our nRF52-DKs. We have ported our app quite seamlessly but we are a bit stuck with the bootloader. Our previous bootloader in the existing product is very simple, not secure and it communicates with UART. This is a marine product so we want to do away with any cables and perform DFU via BLE. Security is not really a requirement for us, we would happily use the extra memory to add features to our app. Also, once it is working, we do not envision having to update the bootloader itself, only the app. Reading the documentation, it looks like Nordic is recommending the use of the B0 secure bootloader. It also looks like, if DFU over BLE is required, MCUBoot is required as a second stage bootloader. Is it possible to use only one bootloader given our requirements? Any recommendations four our product would be welcome.

Now more questions regarding the actual procedure that is not working for us even in the simplest of cases. Here are some details about our setup:

• NRF52-DK
• VS Code as IDE
• SDK and toolchain version 1.9.1
• Mac OS (other engineers use windows)

We created an app based on samples/blinky where we added CONFIG_SECURE_BOOT=y entry to the prj.conf file. We also generated a private key using nrfutil and added the corresponding file CONFIG_SB_SIGNING_KEY_FILE="/path/to/private.pem". Building the app and looking at the memory map, it does appear that the bootloader is compiled in and using the region 0x0000 to 0x7000. Moreover, when flashing the app we see it goes thought the bootloader chain...

*** Booting Zephyr OS build v2.7.99-ncs1-1 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8000.
Verifying signature against key 0.
Hash: 0x09...e6
Firmware signature verified.
Firmware version 1
*** Booting Zephyr OS build v2.7.99-ncs1-1 ***

and then it goes on blinking as one might expect. So far, so good (we think).

Now, we want to replace the app using the bootloader by another one blinky_fast where we have changed the blinking rate to be faster. So we created this new app from the blinky template. We took the hex file from ../blinky_fast/build/zephyr/zephyr.hex and went on to generate a zip package using nrfutil like so...

nrfutil pkg generate --hw-version 52 --sd-req 0x124 --key-file /path/to/private.pem --application-version 1 --application /path/to/zephyr.hex /path/to/blinky_fast.zip

We can see that the Zip is created...

Zip created at /path/to/blinky_fast.zip

If we inspect the contents by running...

nrfutil pkg display /path/to/blinky_fast.zip

It all looks ok to us. We can provide this output if needed.

We think we are doing fine thus far. Now we try to do the actual dfu over UART like so...

nrfutil dfu serial -pkg /path/to/blinky_fast.zip -p /dev/tty.usbmodem0006825573701 -b 115200

The DK-52 is connected as usual to the PC via USB cable. tty.usbmodem0006825573701 is the virtual comm port name assigned by the OS when the USB cable is plugged in.

A progress bar appears but it never moves from 0%. Eventually, we see the dreaded

"No ping response after opening COM port"

We have looked at other issues with similar problems (devzone.nordicsemi.com/.../serial-dfu-bootloader-example---no-ping-response-after-opening-com-port and devzone.nordicsemi.com/.../pc_ble_driver_py-exceptions-nordicsemiexception-no-ping-response-after-opening-com-port) but we don't find a solution. We are really stuck and would appreciate your kind help.

[Susheel Nuguru]

Not an expert in the DFU stuff but it seems like your image package seems ok but the transfer is not able to go further because of the UART communication. Are you sure that the UART on both ends are configured correctly? (correct baudrate and correct flow control configured)

[Bruno Miguelez]

We have checked UART configuration in both ends and tried with lower baudrates too, but we get the same result. We have also tried connecting an external UART cable directly to the pins instead of using the micro usb cable but it didn't change anything either. We don't really understand when does the board wait for dfu communication with pc. As we specified above, when adding the CONFIG_SECURE_BOOT=y it then prints out the messages above, so we know that it goes into the dfu code. However, in older versions we have read that it used to wait for button 4 to be held during a reset to stay in the dfu code and waiting for communication with the PC. We are not sure if ours is waiting for communication with the PC as it seems to go immediatly into the app image.

[Susheel Nuguru]

Sorry for the late response, I would ask my colleague to help as I do not have experience with the older versions of bootloader.

[Vidar Berg]

Hello,

I'm afraid you will not be able to DFU over BLE working on the 52810 because of the limited amount RAM and FLASH you have available. You need to be able to fit the application and MCUBoot inside the internal flash as well as having enough RAM to include the DFU related modules. Also, for DFU over BLE, an external SPI flash IC will be required as the application needs a place to store the new FW image before it gets activated by the bootloader. 

I did as a test  try to configure an example with external flash and BLE DFU support following the steps in "FOTA upgrades", but I struggled to get the RAM usage below 40 K, which is way above what the 52810 has. So it does not look promising, unfortunately.

Memory layout for illustration

The B0 Bootloader (nRF Secure Immutable Bootloader) is for added security and is targeted for the larger variants of the 52 family. It's not suitable for the 52810 because of the memory constraints. It also does not handle DFU (the application and/or MCUBoot is responsible for that).

nrfutil dfu serial -pkg /path/to/blinky_fast.zip -p /dev/tty.usbmodem0006825573701 -b 115200

nrfutil is for performing DFU over the Secure DFU protocol used in the nRF5 SDK. The equivalent tool for this in the nRF connect SDK is the mcumgr cli: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#installing-the-mcumgr-cli 

I understand that it is not desirable to change the chip variant at this stage, but is it something you could consider? You can find an overview of the different nRF52 variants here: nRF52 Series

Best regards,

Vidar

[Bruno Miguelez]

Hello

Thank you for your response. It is not a big issue for us to change from the 810 to the 832. However we don't like that much the idea of adding a SPI Flash IC. From what we understood, what you tried to do was to follow the FOTA Uprades documentation with the external SPI flash IC and the 810 because the 810 doesn't have enough Flash, but when trying this it turns out that it doesn't have enough RAM either. So a change to the 832 will fix both issues right? So there is no need to add the SPI IC if we change to 832 right?

We are working right now with the DK so it is not a big deal for us to change to the 832, in fact we have already tried to follow the same FOTA Upgrades documentation that you mentioned with the mcumgr with 832.  We added CONFIG_MCUMGR_CMD_OS_MGMT, CONFIG_MCUMGR_CMD_IMG_MGMT, and CONFIG_MCUMGR_SMP_BT in prj.conf and os_mgmt_register_group() and img_mgmt_register_group() in the app, as well as smp_bt_register(). Then we tried using the nrf Connect Device Manager app in our mobile phone to start BLE communication but it turns out the board wasn't advertising or at least our phone couldn't find it in its nearby bluetooth devices. We then tried with by flashing the SMP Server Sample app and got the same results. Do you have any idea of why this could be happening?

It is worth mentioning that all we need from the dfu is to replace the existing application with the new version, we don't need to upgrade neither the softdevice or the bootloader itself, so what we would like is the most straight forward way of doing this through BLE. Thank you so much for your responses again.