MCUBoot configuration for the custom Adafruit feather nrf52840

[EthanH]

Hello there,

Recently I tried to configure the MCUBoot on my custom Adafruit feather nrf52840, based on the Windows.

Firstly, I followed the instruction below to configure the MCUBoot on the nrf52840DK, and it works.

https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/software/posts/device-firmware-update-dfu-with-mcuboot-bootloader

It built the hex file by the commands "west build -b nrf52840dk_nrf52840 --pristine -- -Dmcuboot_OVERLAY_CONFIG=<path>/usb_cdc_acm_log_recovery.conf"

and then simply give "west flash", it successfully flashed by nrfproj, and then I can see the MCUboot is set up and ready to go.

 

Afterwards, I can use mcumgr to upload the image, so everything was good for the nrf52840DK.

Then, I moved on my custom Adafruit feather nrf52840. I connected the nrf52840DK with the my PCB like:(using the JLink from nrf52840DK)

https://www.hackster.io/news/getting-zephyr-running-on-the-nrf9160-feather-6c5e20a2a350

The same procedure was operated and it successfully built the hex file as well by "west build -b adafruit_feather_nrf52840 --pristine -- -Dmcuboot_OVERLAY_CONFIG=<path>/usb_cdc_acm_log_recovery.conf", just change the board name here.

For the usb_cdc_acm_log_recovery.conf, give the CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000, and also CONFIG_BOOT_SERIAL_DETECT_PIN=11, using the nrf52840DK (PCA10056)

However, when I use the west flash, it indicated the error here.

I think it is mainly relevant to the JLink setting.

Can you please tell me the reason or what is different configuration for using nrf52840DK to debug out the custom nrf52840 based board?

Thanks in advance for any suggestions.

Regards,

Ethan

Issue update:

As suggested, added the JLInk to the environment variable, and it works for JLink flashing.

But it got the access denied and the program was actually not implemented.

Thanks for any suggestions!

Update!

Change to the nrfjprog flashing replacing the JLink in the cmake configuration file.

It works to west flash.

While there is no response for the adafruit feather nrf52840 board, no serial port appears.

So I tested the nrf52840DK as the reference, I can see the bootloader start indicated in the debugging  terminal when west flash the program

While for the custom adafruit feather nrf52840, it is nothing shown in the terminal.

I think the current issue is relevant to the MCUBoot configuration or serial recovery mode.

Here is my MCUBoot configuration:

Please share the suggestions if you get some ideas.

Regards,

Ethan

[EthanH]

Hello Vidar,

Firstly thank you so much for the suggestion.

It works for the Jlink flashing while it got the access denied issue for program implementation now.

You can check the update results in the above post, and if you have the idea.

And appreciate for your help.

Best Regards,

Ethan

[EthanH]

Hello Vidar,

Thanks again for your prompt suggestion.

It works to flash the program by nrfjprog after following your setting.

But there is no response after the west flash and nrfjprog -r (reset).

As the reference, when I west flash to the nrf52840DK, I can see the bootloader start and serial recovery mode indicated at the debugging terminal. 

While there is nothing shown at the terminal when west flash the adafruit feather nrf52.

Please check the update post above.

I think the current issue is mainly relevant to the bootloader configuration, if you can share your idea. 

Best Regards

Yuxiang

[Simon]

EthanH said:

While there is nothing shown at the terminal when west flash the adafruit feather nrf52.

Have you been able to get log output from the Adafruit feather nrf52840 at all?

Could you start from scratch and figure out exactly where you stop getting log outputs?

• 1. Program the sample zephyr/samples/hello_world onto the Adafruit feather nrf52840 and check if you get the following output (different board name):

*** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
Hello World! nrf52840dk_nrf52840

• 2. Add CONFIG_BOOTLOADER_MCUBOOT=y to zephyr/samples/hello_world/prj.conf, delete the build folder and build and program the hello world sample again. Check if you get log output similar to this:

*** Booting Zephyr OS build v2.6.0-rc1-ncs1 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v2.6.0-rc1-ncs1 ***
Hello World! nrf52840dk_nrf52840

• 3. If that works fine, then try follow https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/software/posts/device-firmware-update-dfu-with-mcuboot-bootloader and see if you're able to see the log

At which step do you stop seeing the log?

[EthanH]

Hello Simon,

Thank you for the info.

Sry for the delay, as I was busy for other stuff.

According to your comments, I reviewed the procedure for the nrf52840DK and adafruit feather separately.

1. For the nrf52840DK, as I saying, everything looks good to configure the MCUBoot and implement the program here.

Yes, I saw the terminal output as you mentioned in the section 1.

And there is a little difference for the section 2, as I checked the result below:

*** Booting Zephyr OS build v2.4.0-ncs1  ***
[00:00:00.349,731] <inf> mcuboot: Starting bootloader
[00:00:00.349,761] <inf> mcuboot: Enter the serial recovery mode
[00:00:00.354,278] <inf> usb_cdc_acm: Device suspended
[00:00:00.454,498] <inf> usb_cdc_acm: Device resumed
[00:00:00.454,528] <inf> usb_cdc_acm: from suspend
[00:00:00.578,796] <inf> usb_cdc_acm: Device configured
*** Booting Zephyr OS build v2.4.0-ncs1  ***
*** Booting Zephyr OS build v2.4.0-ncs1  ***
Hello World! nrf52840dk_nrf52840

However, I think it didn't affect the following processing that I had detected the image list for the new serial port after west flash.

I did see the required result in the end which means the MCUBoot flashing was working for the nrf52840DK.

2. For the adafruit feather, same procedure was operated until the west flash. After the west flash, I can't find the new serial port regarding the MCUBoot.

Meanwhile I didn't see the output same as the picture 1 I posted.

In addition, I also tried the blinky sample for the adafruit feather, I can see the light is blinking on the adafruit feather board, but no serial port appeared to check the MCUBoot image list.

Based on my understanding, it actually flashed the program by the nrfjprog or jlink by the west flash while it didn't configure the MCUBoot.

Can you please provide some suggestions here? Thanks again for your help.

Best Regards,

Ethan

[Simon]

I don't think the issue is related to the MCUBoot, but with the serial logging itself.

Logging using the Adafruit Feather nRF5284 is configured to use UART0 by default

https://github.com/nrfconnect/sdk-zephyr/blob/v2.6.99-ncs1/boards/arm/adafruit_feather_nrf52840/adafruit_feather_nrf52840.dts#L16

UART0 uses the pins 25 and 24

https://github.com/nrfconnect/sdk-zephyr/blob/v2.6.99-ncs1/boards/arm/adafruit_feather_nrf52840/adafruit_feather_nrf52840.dts#L74-L75

The nRF52840 DK connects UART0 to the Interface MCU, which exposes it as a Virtual COM port, which enables you to see the serial log. This is not the case for the Adafruit board.

Solutions

• RTT logging
  • Which goes through the 10pin cable and SWD, which I can see in the picture that you have connected to the nRF52840 DK
  • The flow is the following: pc <--- usb ---> nRF52840 DK <-- SWD --> custom board
  • Follow the approach in the answer below to get RTT logging to work:
    • https://devzone.nordicsemi.com/f/nordic-q-a/61864/unable-to-use-rtt-in-nrf91/251989#251989
  • By the way, if you want to get RTT logging to work with MCUboot, it won't help to modify the application's prj.conf, since mcuboot is a child image with it's own prj.conf file. Check out the external_flash sample to see how to configure child images from the application
• USB to TTL serial cable
  • E.g. this one: https://www.adafruit.com/product/70
  • Connect the cable to your UART0 pins and to the computer

Best regards,

Simon