DFU with UART through LTE Modem

[jswcomkr]

I'm developing FOTA through LTE Modem which is made from QUECTEL(EC21KL)

On my custom board, nRF52832 is connected with EC21 LTE Modem via UART bus(TX : P0.16, RX : P0.17).

I successfully downloaded new firmware from our server to EC21KL LTE modem, but I cannot execeute DFU through UART.

I don't know how can I set the pins for UART DFU.

How can I do this?

I attached some part of circuit design.

Summary.

1. How can I assign the pins for UART DFU?

2. How can I transfer new firmware through UART?

Thank you.

[Hung Bui]

Hi정성욱, 

Could you explain a little bit more about the LTE module ? Do you have an MCU on the module ? 
What's the protocol you have between the nRF52 and the Modem ? is it AT Command or your own proprietary UART protocol ? 

If you have an MCU on the LTE module, then you need to think about implementing UART DFU from the MCU to send the image to the nRF52. You can have a look at my example here. 

[jswcomkr]

Hi. Thank you for reply.

nRF52832 is connected with QUECTEL EC21KL LTE module via UART pins.

This is simple schema of my system.

I'm using standard AT Commands.

[Hung Bui]

Hi, 

Thanks for clarification. I assume there is no MCU on the LTE Module that you can write code to send the image to the nRF52. 

And the image is stored (after downloading from the cloud) somewhere in the LTE module memory that you can access using AT command from nRF52 ? 

In that case there isn't a out of the box solution that you can do DFU straight from the LTE module. 

What you need to do is to write your own code to read the image, from the LTE module, and then store it to the internal flash of the NRF52 . And then after that jump to the bootloader and let the bootloader swap the image. 

Could you let me know how familiar you are with the DFU bootloader that we have in the SDK ? I assume you are using nRF5 SDK ? 

[jswcomkr]

Thanks for advise. I understand booting orders and procedures.

Would you check the procedure for DFU?

1. Go to DFU mode

2. call the uart_dfu_transport_init()

3. Start transferring from LTE Modem using AT Commands

4. After copy, swap the image to main bank(probably bank 0?)

Is it right?

[Hung Bui]

Hi, 

Yes it's one way of doing it. With this approach you would need to implement the AT Command in the bootloader. I'm not very familar with that so I can't comment here. 
Another option is to integrate the transferring (step 3) into your application. 
So basically: 

1. Application tells the Modem to download the image 

2. The image has been downloaded to the Modem

3. The application transfer the image from the Modem to the internal flash space 

4. The application prepare the bootloader setting then reset to the bootloader

5. The bootloader read the bootloader setting and swap the image that the application downloaded to main bank

6. The bootloader start the new application. 

Both approaches would work. In your approach you don't have to modify the application much and only need to modify the bootloader. The second approach called background DFU meaning your application still run normally when receiving the image to the NRF52 and only switch to bootloader to swap. But it require more modification in the application and is not supported out of the box (you need to follow the background DFU example) 

So all in all, I think your approach is more suitable if the implementation of the AT command to get the image is not too complex that it can be implemented in the bootloader, then it's fine. 

[jswcomkr]

Oh thank you very much.

Do you have any tutorials for bootloader?

I can modify bootloader a little bit, but I have no experince in handling the memory space of the bootloader.

[Hung Bui]

Hi, 

We unfortunately don't have an example that show you how to modify the bootloader.

If you go for that approach, you are replacing the DFU protocol to use with your own protocol. I guess what you need to keep is the verification of the image with the hash signature , the part where the bootloader write to bootloader setting to be ready to swap the image on the next reset. 

It's up to you on what you want to adapt from our bootloader, and which part you want to define to your own protocol.