Firmware Updates over UART w/Custom board using NRF52820, No Buttons, no LEDs

[JeffCat]

Current goal is to be able to program, and upgrade with the radio off, and the only connection as a UART.

But I'm both overwhelmed by the number of options (DFU, SMP, and/or MCUMGR) , and unable to find a reliable starting point. I think my question boils down to:
What are the minimal requirements to allow an initial, and future firmware upgrades over UART?

• Device tree: UART Tx & Rx pins are swapped from default
• proj.conf: (CONFIG_DFU_TARGET, and or CONFIG_MCUMGR...)
• CMakeLists.txt: Looks like no libraries, or other sources but main.c)
• and source code  - which is only main, which is only a sleeping loop, but might need more to allow future firmware upgrades.

I've unsecured the NRF52820 due to a poor programmer connection... Do I have to re-install any additional images?

I've tried starting the SDK17 secure_uart bootloader sample, with a custom board, and modified makefile (micro & no FPU), modified the linker according to  case about nRF52820 uart dfu.  And was unable to start communication. Is another image such as MCUBoot supposed to be at offset 0? Wheres the image?

I've tried the 2.6.1 toolchain SMP_SVR sample, and get a cmake error, No fprotect backend selected, while attempting to fix that ran into undefined reference to `z_nrf_clock_control_lf_on`

[Hieu]

Hi JeffCat,

I've tried starting the SDK17 secure_uart bootloader sample, with a custom board, and modified makefile (micro & no FPU), modified the linker according to  case about nRF52820 uart dfu.  And was unable to start communication. Is another image such as MCUBoot supposed to be at offset 0? Wheres the image?

First of all, I would like to address this point. Unless you have a strong reason to do so, you shouldn't mix SDK. Since you are using the nRF Connect SDK, you shouldn't try to make the nRF5 SDK Secure Bootloader to work.

It is possible, and I can answer your questions about it, but I recommend against this.

But I'm both overwhelmed by the number of options (DFU, SMP, and/or MCUMGR) , and unable to find a reliable starting point. I think my question boils down to:
What are the minimal requirements to allow an initial, and future firmware upgrades over UART?

I understand being overwhelmed by the number of configurations. To keep things more manageable, please just keep the configurations at their default value. The solution is meant to work well with that.

To help ease you into the topic, may I suggest taking a look at Lesson 8 of our free online course on the nRF Connect SDK?

My colleague Sigurd also has two unofficial samples that demonstrate DFU over UART:
mcuboot_smp_uart at main · hellesvik-nordic/samples_for_nrf_connect_sdk (github.com)
serial_recovery at main · hellesvik-nordic/samples_for_nrf_connect_sdk (github.com)

I've unsecured the NRF52820 due to a poor programmer connection... Do I have to re-install any additional images?

Could you please explain the problem in further details? I am afraid I don't understand what "unsecured" means here.

Hieu

[JeffCat]

Thank you Hieu, I will look over those 3 resources

"unsecured"  - The programmer in NRF Connect indicated the microcontroller was secured (reading flash over the programming interface is denied). Unsecure is a process to erase the entire flash area, which would include erasing MCUBoot, or any other images. Though it appears MCUBoot is included in the smp_svr sample's merged.hex.

[Hieu]

I see, that means that Access Port Protection was originally being enabled and was then disabled.

No worries about that then.