Firmware Update over UART Interface

[Jatala]

Hello,

Background: I have a custom board that contains nRF52832 module and exposes UART pins (RX, TX, RTS, CTS). I have developed an application using nRF5 SDK v17.0.2. The application does not use any so -called SoftDevice.

Objective: I want to develop a mechanism to update the application firmware of on the nRF52832 module over the UART interface from another micro-controller.

Seeking Help: After searching through the SDK and the forum, it looks like I have to use libraries under Bootloader and DFU modules But I am still confused which components to use and in what order. On the nRF52832 module, do I need to program, as part of my application, routines to receive and process DFU commands/data packets. I am also using the same UART port to exchange application data (from sensors attached sensors )  with the other micro-controller.

I would appreciate any help that can get me started on the right path to achieve the objective.

[Hung Bui]

Hi Jatala, 

I would suggest you to get started with our uart bootloader located inside examples\dfu folder. There are 2 options, secured DFU and open DFU. It depends on your need you can choose to use one. 

The DFU example allow you to do DFU via UART from either PC (nrfutil.exe on PC) or from external MCU (official example is not included). 

I have made an example of doing DFU from one MCU to another MCU here.

I would suggest to get familiar with these resource first, so that you can do DFU from one MCU to another MCU. 

What's missing here is to combine that to your application. What you want to achieve may be accomplished by implementing a command to switch from your application to the bootloader and from there the bootloader can receive the image and update the application. The limitation is that your application will be stopped when the bootloader receiving the image. But the advantage is that you only need to switch to the bootloader, and don't need to modify anything. 
Another option is to implement background DFU where your application will receive the image and then only switch to the bootloader to swap the image. This would require some implement on your application code to receive image that we don't have example code for now. 

Note that the bootloader, when not to be used with the softdevice would need the MBR to be flashed to run. Please refer to the bootloader documentation. 

[Jatala]

Hi Hung,

Thanks for the insight. I will go though the sources that you have pointed out and will come back to this thread if stumbled upon any issue.

The first approach seems simpler to implement. "...implementing a command to switch from your application to the bootloader and from there the bootloader can receive the image and update the application", so in this case, the bootloader will be responsible to receive the application over the UART. But how the configuration and registration of the UART will be handled. I suppose it has to done from my application, right?

[Hung Bui]

Hi, 

Error 4 you see is most likely the UART FRAMING error. Please check the ERRORSRC in the UART peripheral in the nRF52 spec. 

If you add a breakpoint inside uart_event_handler() in nrf_dfu_serial_uart.c you may catch the error. 

I would suggest to test with normal UART example and make sure it works first. 

If normal application works but not the bootloader, you may want to hook a logic analyzer to check if the communication would work properly. 
I don't see any reason why RX pin doesn't work with pin 9 10 11. 

[Jatala]

Hi,

- Error 4 value in  ERRORSRC register corresponds to TX buffer over-read... what link UART RX pin has with the TX buffer?

- Captured the error in the uart_event_handler() and it shows error_mask = 0x0000000C.  Could not find in the SDK any description of this error-mask!

- In normal application program I am using the same UART port (to send and receive data, but without hardware flow-control) and never faced any problem. 

I would appreciate any thought that could be helpful.

[Hung Bui]

Hi Jatala, 
In your screenshot it's chapter 34 are you sure it's about UART ? UARTE and UART is on chapter 35 and 50. 

What you showed in the screenshot is for TWI. 

0x0C in the error mask meant both FRAMING and BREAK got error. 

[Jatala]

Thanks for the correction. I am wondering why with the Rx pin, such an error is thrown. 

[Hung Bui]

You need to test with a simple UART example, to check if you can communicate normally with the external MCU via the TX and RX pin you defined. 
Having a floating RX pin will cause such error. 

[Jatala]

Hi Hung,

After quite a bit of struggle I found a way out of the UART problem. I am able to run the same code (with UART RX Pin 11) on another sample of the same board. So somehow pin 11 on the previous samples was malfunctioning.   The bootloader works fine, enabling the uart transport layer, and enters 'loop_forever' function waiting for the DFU trigger event.

Now in the next step I attempted following tasks:

- While following your tutorial, I was trying to .zip file from my app.hex. With the command  'nrfutil pkg generate'  argument  '--sd-req' is required. However I am not using any softdvice in my application. But looks like I have to provide some value to this argument but which one?

- I generated bootloader setting hex file

nrfutil settings generate --family NRF52 --application app.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 bld_setting.hex

Then with 'mergehex --merge' command merged the setting hex file with bootloader and app hex files. But when I tried to program the resulting merged file (using Programmer tool in nRF Connect app) I get error "Overlapping data around address 0x7d12c". Any way out?

- Using command 'nrfjprog --reset --program mergd.hex --family NRF52 --sectoranduicrerase',   the programming of the merged hex file is successful. Howerever, he bootloader does not entered when the application program sets NRF_POWER->GPREGRET and does softreset of the device.


[Hung Bui]

Hi Jalata, 

I would suggest to try testing with BLE DFU as well just to get familiar with the process. 

If you have a look at the documentation of the nrfutil here you can find that if you don't use softdevice you can use any --sd-req value, it will be ignored when doing DFU. ( I suggest to use  0xFF)

Please send the full log when you do mergehex, as well as the bootloader, application, and bootloader setting. Please try testing with one of our application example before testing with your own example. 

[Jatala]

Hi Hung,

See files (bootloader, bootloader setting, application, and merged) in attachment 7384.bootloader.hex. , 5241.bootloader_setting.hex, 4645.app.hex, allmerged.hex

Here is output log from relevant commands :

>  nrfutil settings generate --family NRF52 --application app.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 bootloader_setting.hex

Note: Generating a DFU settings page with backup page included.
This is only required for bootloaders from nRF5 SDK 15.1 and newer.
If you want to skip backup page generation, use --no-backup option.

Generated Bootloader DFU settings .hex file and stored it in: bootloader_setting.hex

Bootloader DFU Settings:
* File:                     bootloader_setting.hex
* Family:                   nRF52
* Start Address:            0x0007F000
* CRC:                      0x00197635
* Settings Version:         0x00000002 (2)
* App Version:              0x00000000 (0)
* Bootloader Version:       0x00000000 (0)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x000045EC (17900 bytes)
* Application CRC:          0x3ACE56BA
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0xE04E9893
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

> mergehex --merge bootloader_setting.hex bootloader.hex app.hex --output allmerged.hex
Parsing input files.
Merging file "bootloader_setting.hex" into output.
Merging file "bootloader.hex" into output.
Merging file "app.hex" into output.
Storing merged file.

> nrfjprog --reset --program allmerged.hex --family NRF52 --sectoranduicrerase
Parsing image file.
Erasing page at address 0x0.
Erasing page at address 0x1000.
Erasing page at address 0x2000.
Erasing page at address 0x3000.
Erasing page at address 0x4000.
Erasing page at address 0x5000.
Erasing page at address 0x78000.
Erasing page at address 0x79000.
Erasing page at address 0x7A000.
Erasing page at address 0x7B000.
Erasing page at address 0x7C000.
Erasing page at address 0x7D000.
Erasing page at address 0x7E000.
Erasing page at address 0x7F000.
Erasing UICR flash area.
Applying system reset.
Checking that the area to write is not protected.
Programming device.
Applying system reset.
Run.

> nRF52832 device memory map after flashing the allmerged.hex file

> When tried to open allmerged.hex file with Programmer tool in nRF Connect app, got error message "Overlapping data around address ....".

[Hung Bui]

Hi, 
Please check your  mergehex.exe, because when I did exact command you used: 
mergehex --merge bootloader_setting.hex bootloader.hex app.hex --output allmerged.hex

I got a allmerged2.hex and I can flash withour any problem. 

However, there is an issue that you don't flash the MBR. I mentioned in the previous reply, if you don't flash the softdevice you need to flash the MBR (located at \components\softdevice\mbr\hex) . It's the piece of code that execute the bootloader instead of the application when the device booting up. 

And also you need to move your application to address 0x1000 when you use it with the MBR, please have a look at the Blinky example which we has the MBR version: \examples\peripheral\blinky\pca10040\mbr

[Jatala]

Thanks Hung,

- As I reported in my last two posts. The flashing of allmerged.hex file works with 'nrfjprog --reset --program allmerged.hex --family NRF52 --sectoranduicrerase' command. But when the same file is opened with the Programmer tool in nRF Connect app, gives error message "Overlapping data around address ....".

- For the MBR, I just take the hex file from \components\softdevice\mbr\hex and merge it with the others and then flash the result, right?

- Moving application to address 0x1000, I suppose I need to specify this in the Linker settings (Segger Embedded Studio) of application, very much like it is done in the configuration of  \examples\peripheral\blinky\pca10040\mbr