Example For Using UART DFU on NRF52832 on both sides of communications

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Simon — Thu, 06 Oct 2022 08:54:44 GMT

I just created an nRF Connect SDK solution that support DFU from chip to chip, check it out here: https://github.com/simon-iversen/ncs_samples/tree/master/central_smp_client_dfu

Best regards,

Simon

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Simon — Wed, 25 May 2022 12:05:59 GMT

[quote user="pkeiles"]I was also working with our local application engineer on investigating an approach to use the serial DFU update within mcuboot directly. The downside of this approach is having to support with one of the mcumgr protocols on the main processor downloading the image (newtmgr or smp possibly).[/quote]

Actually, you can modify mcuboot serial recovery (perform DFU update within mcuboot directly) to not use the mcumgr protocol, like I explained earlier. Be aware that if you perform DFU through the MCUboot, you put the image directly into the primary slot (not in the secondary slot like you do when performing the DFU through the application), and swapping won't happen. This is because mcuboot acts as the fallback recovery if the update fails.

[quote user="simoniversen"]

Pamela Keiles said:
Can I include all support for the firmware image update via the UART within the bootloader code? And if so, is the smp protocol the only option?

Yes, you can do this. If you want to perform a UART DFU through mcuboot you need to use smp/mcumgr protocol. However, only a limited set of commands are supported, as you see here: https://github.com/nrfconnect/sdk-mcuboot/blob/v1.8.99-ncs1/boot/boot_serial/src/boot_serial.c#L502-L527

If you want to drop the smp/mcumgr, you need to modify MCUboot, which might require less work that using the smp/mcumgr protocol (where you need to implement the protocol on the client side).

The modification of mcuboot, will happen to the function boot_serial_input(), and instead of parsing the incoming messages as mcumgr commands, you simply store the image blocks right into flash where it belongs.

[/quote]

[quote user="pkeiles"]Thanks again, hopefully I have enough now to get this design piece working quickly.[/quote]

Good luck with the implementation!

Best regards,

Simon

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Tue, 24 May 2022 23:00:35 GMT

Hi Simon,

Thank you so much for the detailed response. I was also working with our local application engineer on investigating an approach to use the serial DFU update within mcuboot directly. The downside of this approach is having to support with one of the mcumgr protocols on the main processor downloading the image (newtmgr or smp possibly). I think that might require more development time than the approach we have already been discussing here.

What I was struggling with was creating a partition manager yml file from scratch to ensure static addresses. But now I see I can copy the build generated yml file as a starting point and adjust it if needed. I don't like the dynamic approach because if something changes in the future with the bootloader itself (programmed during manufacturing), then I have to worry about any possible addressing changes. I believe it's safer to use a static file and ensure the flash sections remain fixed.

I'll work with what we've already outlined and use my own very simple protocol or even xmodem to do the UART transfer from the main processor and flash programming.

The only part that still seems wrong to me is that whatever is specified in the flash data structure within the device tree file is meaningless. However it is still required to do the build (I tried removing it as a test). I suppose though as you say this is still a work in progress.

Thanks again, hopefully I have enough now to get this design piece working quickly.

Best regards,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Simon — Tue, 24 May 2022 13:23:50 GMT

[quote user="pkeiles"]Those "other DFU examples" are related to using external flash, I'm trying to write to the internal flash directly with the new application image.[/quote]

Yes, I was just trying to point you to an example that shows how the pm_static.yml file might be used. Sorry for the confusion.

[quote user="pkeiles"]What is the point of defining the flash partitions in the board.dts file if they are ignored by the partition manager?[/quote]

The reason it is set in the dts file is because that's how was done in Zephyr upstream (NCS contains a downstream version of Zephyr). Also if you don't have a multi image build, the DTS files will be used. Nordic created the Partition Manager to handle multi image builds, because DTS must be set before Kconfig (when building the project, it will first go through the DTS file and set the memory layout, then it will look at all the configurations (Kconfig, prj.conf and so on)). If DTS would be used, we would need to have an own dts file for all possible configurations.

Be aware that Kconfig and the devicetree in Zephyr is inherited from Linux (see the Zephyr Wikipedia page), which was written for computers with more memory and resources. Zephyr is open source and work in progress.

Hopefully we will soon get the same solution in NCS as Zephyr upstream now uses, the system device tree.

[quote user="pkeiles"] I'm assuming I can't just not use the partition manager?[/quote]

That is correct. You need to use the Partition Manager for now

[quote user="pkeiles"]This design approach seems to be so over-complicated for what I am trying to do.[/quote]

Actually, your project is quite simple. You don't need to add any pm_static.yml file or do anything. Just build your project with CONFIG_BOOTLOADER_MCUBOOT=y in the prj.conf, and then check the generated file <sample>/build/partitions.yml or (<sample>\build\zephyr\include\generated\pm_config.h). Look for two things, the start address of secondary slot(mcuboot_secondary) and the size of secondary slot.

Now you just need to write your new uploaded image to that location. I also think you can just use the generated macros from pm_config.h to get the size and address of the secondary slot.

Please get back to me if you encounter any issues with this.

[quote user="pkeiles"]Sorry to complain, but I've been doing this work for well over 30 years and I find that this whole Zephyr approach is not very user friendly and is very time consuming.[/quote]

I understand your frustration. Zephyr is quite different from other approaches. It is more abstract and moves you further away from the bare metal drivers, and it is a lot of new stuff to learn if you're new to this.

This texts may be an instersting read: https://www.zephyrproject.org/leveraging-open-source-software-in-your-software-development-kit-nordic-semiconductors-experience-with-the-zephyr-rtos/

Best regards,

Simon

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Mon, 23 May 2022 22:25:03 GMT

Hi Simon,

Those "other DFU examples" are related to using external flash, I'm trying to write to the internal flash directly with the new application image.

What is the point of defining the flash partitions in the board.dts file if they are ignored by the partition manager? I'm assuming I can't just not use the partition manager? This design approach seems to be so over-complicated for what I am trying to do.

Sorry to complain, but I've been doing this work for well over 30 years and I find that this whole Zephyr approach is not very user friendly and is very time consuming.

Thanks for your help and regards,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Simon — Mon, 23 May 2022 22:05:45 GMT

When your project contains child images (like mcuboot), the Partition Manager will be used to partition the images instead of the device tree. It will go through the pm.yml files from all the child images and dynamically place the images, and eventually it will place the app where it's room left. Read the documentation for more information: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.1/nrf/scripts/partition_manager/partition_manager.html

You can also set the partitions statically using a pm_static.yml file, for example like it's done in Other DFU samples, or in the maching learning application

Please let me know if anything is unclear

Best regards,

Simon

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Mon, 23 May 2022 21:58:53 GMT

Hi Simon,

I'm struggling with accessing the flash partition area directly using the partition manager defines and the device tree specification for my board. I was referencing the "soc_flash_nrf" example, but it doesn't seem to incorporate the partition manager, which I believe is automatic when using "mcuboot" correct?

I have also been looking at the resultant defines in the "pm_config.h" file, and they are not what I would expect from my board.dts file.

Specifically the sizes and start addresses seem wrong. Here is how the flash is defined in my device tree file:

&flash0 {

partitions {

compatible = "fixed-partitions";

#address-cells = <1>;

#size-cells = <1>;

boot_partition: partition@0 {

label = "mcuboot";

reg = <0x00000000 0xc000>;

};

slot0_partition: partition@c000 {

label = "image-0";

reg = <0x0000C000 0x32000>;

};

slot1_partition: partition@3e000 {

label = "image-1";

reg = <0x0003E000 0x32000>;

};

scratch_partition: partition@70000 {

label = "image-scratch";

reg = <0x00070000 0xa000>;

};

storage_partition: partition@7a000 {

label = "storage";

reg = <0x0007a000 0x00006000>;

};

However when I look at the resultant "pm_config.h" file, the values do not match. Maybe this is effected by this unexpected "PM_MCUBOOT_PAD_SIZE" added which messes up the defined starting locations of the slots?

I'll keep plugging away at this, but any help you can provide would be great.

Thanks,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Sat, 21 May 2022 15:40:31 GMT

Hi Simon,

Great, I think I got the sequence from your explanations. I'll be working on this part of the design the next couple of days and I'll let you know if I have any other questions. I will also be trying to "break" the bootloader to make sure it recovers nicely, such as only a partial image being present in the second bank.

Thanks for all your detailed help.

Best regards,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Simon — Fri, 20 May 2022 11:21:02 GMT

You do it in the opposite way. After you've programmed the secondary flash with the new image, you force a reboot, then you call boot_write_img_confirmed() routine from the new image (now present in the primary slot).

Like I explained in this answer: https://devzone.nordicsemi.com/support-private/support/288653#permalink=757710

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Thu, 19 May 2022 17:35:05 GMT

Hi Simon,

I will be performing the second slot flash update from the app, which receives it via the UART directly. So it sounds like all I have to do after programming the flash with the new image, is call the "boot_write_img_confirmed() routine and force a reboot, is that correct?

Thanks,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Simon — Wed, 18 May 2022 16:07:07 GMT

Are you referring to boot_write_img_confirmed()? This is present inside a file named mcuboot.h, but it is located inside the zephyr repository, not mcuboot. This will not perform any validation checks or do any swapping, but just mark it as "confirmed". It should be run from the application.

You don't need to care about the validation or swapping of the image. This will happen automatically in mcuboot when it's booted:

Validation:
Swapping (switch):

Best regards,

Simon

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Tue, 17 May 2022 00:58:45 GMT

Hi Simon,

I'm going to try and work with the flash erase/write routines directly for the firmware update. I do remember seeing an API to call within I think mcuboot which can be used to set the newly downloaded image as valid and switch the active image slot. Do you know where this is described or an example of its usage?

Thanks,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Simon — Fri, 13 May 2022 12:52:41 GMT

Yes this is absolutely possible.

[quote user="pkeiles"] Then after it confirms the programming is correct (via a checksum or header/tail data check?),[/quote]

This is actually done by the bootloader, all you need from the current running application, is to place the image into the secondary slot. Then on reset, the mcuboot will check if there is a valid image present in secondary slot and swap it with the image in the primary slot if that's the case. Then, it will boot the new image.

[quote user="pkeiles"]call the correct routines within the bootloader to mark the new image as active and execute the reset.[/quote]

This should be done from within the image itself, like it's done in the https_update sample, so mcuboot won't revert back to the old image on the next reet.

The reason it mcuboot will revert back the images on the next reset is to prevent the product from being bricked, for example if the new firmware is faulty, and causes the device to crash.

Let me create a detailed list of how things happen (when performing a dfu through the application)

Application receives the image, and places it in the secondary slot
The device resets
1. This can be done externally by pressing a button, or within the application itself using sys_reboot() (see \zephyr\lib\os\reboot.c)
MCUboot will run first after a reboot and it can see that there is a new image in secondary slot. It will then check if the image is valid (see MCUboot-->Integrity check)
If a valid image is present in the secondary slot, mcuboot wil swap it with the image in the primary slot
MCUboot will then boot the new update that are now present in the primary slot
The new update will run, and needs to confirm itself ( like it's done in the https_update sample), so MCUboot won't revert back on the next reset

[quote user="pkeiles"]I'm assuming the flash driver routines can just be called directly?[/quote]

Yes, you can. Check out the flash API: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.9.0/zephyr/reference/peripherals/flash.html#overview. Take a look at the example \zephyr\samples\drivers\soc_flash_nrf to see how to use this API. The http_update sample uses the Stream Flash API (through \nrf\include\dfu\dfu_target_stream.h), so that might be worth taking a look at.

Good luck and best regards,

Simon

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Thu, 12 May 2022 16:59:27 GMT

Hi Simon,

Another option is to not rely on the bootloader for the update itself but perform the flash programming within my application. Since there are 2 slots, the current running application can do the flash write directly to the other slot. Then after it confirms the programming is correct (via a checksum or header/tail data check?), call the correct routines within the bootloader to mark the new image as active and execute the reset. Does that sound doable? I'm assuming the flash driver routines can just be called directly?

Thanks,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Simon — Thu, 12 May 2022 13:16:37 GMT

[quote user="pkeiles"]Can I include all support for the firmware image update via the UART within the bootloader code? And if so, is the smp protocol the only option?[/quote]

If you want to drop the smp/mcumgr, you need to modify MCUboot, which might require less work that using the smp/mcumgr protocol (where you need to implement the protocol on the client side).

Please let me know what approach you prefer, and I will assist you with the implementation.

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Tue, 10 May 2022 01:23:25 GMT

Hi Again,

Forget the question related to using the UART, I can figure that out myself by referencing the serial drivers directly in my SDK.

I think I need to focus my question on the usage of the bootloader to directly update the image. I would prefer to have all of the update support handled within the bootloader image. If this requires the usage of the mcumgr/smp protocol, then I can incorporate that within my main processor controlling the upgrade process.

Can I include all support for the firmware image update via the UART within the bootloader code? And if so, is the smp protocol the only option?

Thanks,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Mon, 09 May 2022 21:28:26 GMT

Hi Simon and Kazi,

After working with the "lpuart" example, I think that even it is too over-complicated. First of all, using custom RDY/REQ pins versus the standard CTS/RTS pins will be a concern for me on the other side of the communication. Plus, all I really need is basic UART receive and transmit functionality using RAM buffers and callbacks to the application to process the messages.

I'm new to this whole way of using Zephyr and all of the configuration options, but it seems like using the available libraries and drivers becomes much more complicated having to determine the required "config" defines and the desired API. Isn't there a simpler way to use these drivers for just the Nordic chip? Or worst case, simplistic examples for using the processor peripherals?

Thanks,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Pamela Keiles — Mon, 09 May 2022 20:02:28 GMT

Hi Simon and Kazi,

It seems like the "smp/mcumgr" takes up a lot of code space for functionality that I don't really need. I am fine with using simple custom UART commands to communicate between the 2 processors and program the secondary code slot directly in my application.

Currently I am focusing on the basic UART communication using the "lpuart" example. Can you direct me to an example that does the programming of the second flash slot and uses the bootloader to swap the images? I understand there is a lot of documentation for the "MCUboot" online, but having an example would be very helpful. Also ideally if there are references to the image header to extract the version information, or at least show how to use the driver for updating the flash and swapping the images.

Thanks for your help and regards,

Pam

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Kazi Afroza Sultana — Fri, 06 May 2022 13:45:41 GMT

Hello,

It is possible but we do not have exact sample you are talking about. This is for BLE https://github.com/nrfconnect/sdk-nrf/tree/v1.9.99-dev1/samples/bluetooth/central_smp_client . One thing to be noted that the central_smp_client sample only has the echo command. So you have to add upload, confirm, reset commands in the code by yourself.

BLE layer needs to be swapped with an UART layer. But you do not need to use mcumgr/smp protocol to send the image. The image (bin file) can be sent over UART chunk by chunk. When the image is received its can be put in secondary slot. you can look at this sample and can swap the bt_dfu_smp_command() to UARTfunction https://github.com/nrfconnect/sdk-nrf/blob/v1.9.99-dev1/samples/bluetooth/central_smp_client/src/main.c#L343 .

Thanks.

Best Regards,

Kazi Afroza Sultana

RE: Example For Using UART DFU on NRF52832 on both sides of communications

Simon — Fri, 06 May 2022 13:41:56 GMT

As Kazi explained, it is not necessary to use the smp/mcumgr protocol. This case might be useful regarding that: devzone.nordicsemi.com/.../update-code-via-uart-instead-of-fota-nrf9160