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

[Pamela Keiles]

Hello,

I am trying to figure out which example is the closest fit for our design. We are using a 2 processor solution in our product, and the firmware for the NRF52832 has to be able to be upgraded via the UART connection to the main processor. I have found some examples here, but usually it's using a PC application or over the air which does not apply to our design. Also, I'm confused abut some of the examples on the side of the NRF52832 in terms of performing the update. There are references to a "full modem" update, but what is meant by modem? This will be a simple direct UART communication update, is this done via the application on the Nordic chip or can it be done via the bootloader directly?

This has to be a common approach, I'm just unsure where to start. Note I am using the latest SDK release 1.9.1.

Thanks for your help.

Regards,

Pam

[Simon]

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

[Kazi Afroza Sultana]

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

[Pamela Keiles]

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

[Pamela Keiles]

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

[Pamela Keiles]

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