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?

[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

[Hung Bui]

Hi  Jatala, 
Sorry that I forgot to attach the allmerged2.hex. 
I reattached it here, with the allmerged.hex that you generated. There are some slight different (you can use Notepad++ to compare the 2 hex files) 
So I strongly suggest you to check the mergehex version you are using. 

Please don't use nRF COnnect app for DFU and bootloader project, please use nrfjprog.exe 

You don't even need to use merge hex.

 

Jatala said:

- 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

 => Correct.

allmerged2.hex

8865.allmerged.hex

[Jatala]

Thanks Hung for all the help. Flashing the merged file works and booloader is successfully entered in DFU mode from my application by resetting the bit of the relevant register and softrest. Now I will attempt the DFU over UART.

[Jatala]

Hi Hung,

I generated DFU .zip package for an updated version of application:

nrfutil pkg generate --hw-version 52 --application-version 1 --application appnew.hex --sd-req 0xFF --key-file my_private_key.key app_dfu_package_new.zip

But when tried to do DFU with 'nrfutil dfu serial' command, I get the following error  'Extended Error 0x07: The array of supported SoftDevices for the update does not contain the FWID of the current SoftDevice', although I am not using any softdevice. Any idea how to resolve this problem.

Complete log of the  command 'nrfutil dfu serial' here:

Traceback (most recent call last):
  File "/home/pi/.local/bin/nrfutil", line 10, in <module>
    sys.exit(cli())
  File "/usr/lib/python2.7/dist-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/usr/lib/python2.7/dist-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python2.7/dist-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python2.7/dist-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python2.7/dist-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/home/pi/.local/lib/python2.7/site-packages/nordicsemi/__main__.py", line 1042, in serial
    timeout)
  File "/home/pi/.local/lib/python2.7/site-packages/nordicsemi/__main__.py", line 956, in do_serial
    dfu.dfu_send_images()
  File "/home/pi/.local/lib/python2.7/site-packages/nordicsemi/dfu/dfu.py", line 129, in dfu_send_images
    self._dfu_send_image(self.manifest.application)
  File "/home/pi/.local/lib/python2.7/site-packages/nordicsemi/dfu/dfu.py", line 97, in _dfu_send_image
    self.dfu_transport.send_init_packet(data)
  File "/home/pi/.local/lib/python2.7/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 256, in send_init_packet
    self.__execute()
  File "/home/pi/.local/lib/python2.7/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 421, in __execute
    self.__get_response(DfuTransportSerial.OP_CODE['Execute'])
  File "/home/pi/.local/lib/python2.7/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 502, in __get_response
    raise NordicSemiException('Extended Error 0x{:02X}: {}'.format(resp[3], data))
pc_ble_driver_py.exceptions.NordicSemiException: Extended Error 0x07: The array of supported SoftDevices for the update does not contain the FWID of the current SoftDevice.