• State Not Answered
  • Replies 12 replies
  • Subscribers 69 subscribers
  • Views 1854 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 296598
Options

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.

Parents
  • 0

    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)

  • 0 in reply to Susheel Nuguru

    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.

Reply
  • 0 in reply to Susheel Nuguru

    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.

Children
Related