Firmware Update over UART Interface

RE: Firmware Update over UART Interface

Hung Bui — Tue, 16 Feb 2021 13:01:13 GMT

Hi Jatala,
If you update without a softdevice you should use the --sd-req 0x00 instead of 0xFF, my mistake.

It's described here. Please look for "Updates without a Softdevice" section.

I attached here my mergehex.exe I used. It's version 10.10.0 But I don't think v10.12.1 would be the real cause. Please try merge again.

devzone.nordicsemi.com/.../mergehex.exe

RE: Firmware Update over UART Interface

Jatala — Mon, 15 Feb 2021 20:43:42 GMT

[quote userid="2121" url="~/f/nordic-q-a/70274/firmware-update-over-uart-interface/293292#293292"]So I strongly suggest you to check the mergehex version you are using. [/quote]

That is puzzling. I installed 'mergehex' as a part of 'nRF Command Line Tools' nRF-Command-Line-Tools_10_12_1_Installer_64.exe.

mergehex version: 10.12.1

Could you please tell me the mergehex version that you are using. May be the version that I am using has some bug.

RE: Firmware Update over UART Interface

Jatala — Mon, 15 Feb 2021 19:33:57 GMT

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.

RE: Firmware Update over UART Interface

Jatala — Wed, 10 Feb 2021 18:21:08 GMT

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.

RE: Firmware Update over UART Interface

Hung Bui — Mon, 08 Feb 2021 10:35:42 GMT

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.

[quote user="Jatala"]

- 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

[/quote]

=> Correct.

devzone.nordicsemi.com/.../allmerged2.hex

devzone.nordicsemi.com/.../8865.allmerged.hex

RE: Firmware Update over UART Interface

Jatala — Thu, 04 Feb 2021 23:26:49 GMT

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?

RE: Firmware Update over UART Interface

Hung Bui — Thu, 04 Feb 2021 14:19:11 GMT

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

RE: Firmware Update over UART Interface

Jatala — Wed, 03 Feb 2021 21:18:30 GMT

Hi Hung,

See files (bootloader, bootloader setting, application, and merged) in attachment devzone.nordicsemi.com/.../7384.bootloader.hex. , devzone.nordicsemi.com/.../5241.bootloader_5F00_setting.hex, devzone.nordicsemi.com/.../4645.app.hex, devzone.nordicsemi.com/.../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 ....".

RE: Firmware Update over UART Interface

Hung Bui — Wed, 03 Feb 2021 09:02:19 GMT

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.

RE: Firmware Update over UART Interface

Jatala — Tue, 02 Feb 2021 12:45:17 GMT

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.

RE: Firmware Update over UART Interface

Hung Bui — Fri, 22 Jan 2021 09:01:30 GMT

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.

RE: Firmware Update over UART Interface

Jatala — Thu, 21 Jan 2021 16:49:00 GMT

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

RE: Firmware Update over UART Interface

Hung Bui — Thu, 21 Jan 2021 10:32:59 GMT

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.

RE: Firmware Update over UART Interface

Jatala — Wed, 20 Jan 2021 18:58:06 GMT

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.

RE: Firmware Update over UART Interface

Hung Bui — Wed, 20 Jan 2021 13:49:24 GMT

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.

RE: Firmware Update over UART Interface

Jatala — Tue, 19 Jan 2021 22:58:32 GMT

I tested the secure bootloader debug project. It seems to work fine. But the bootloader program crashes when I change the UART pin assignment in pca10040.h as follows.

Original	Changed
#define RX_PIN_NUMBER 8 #define TX_PIN_NUMBER 6 #define CTS_PIN_NUMBER 7 #define RTS_PIN_NUMBER 5	#define RX_PIN_NUMBER 11 #define TX_PIN_NUMBER 5 #define CTS_PIN_NUMBER 7 #define RTS_PIN_NUMBER 6

Following is the RTT viewer log:

<info> app: Inside main
00> <debug> app: In nrf_bootloader_init
00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
00> <debug> nrf_dfu_settings: Using settings page.
00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <debug> app: Enter nrf_bootloader_fw_activate
00> <info> app: No firmware to activate.
00> <info> app: Boot validation failed. No valid app to boot.
00> <debug> app: DFU mode because app is not valid.
00> <info> nrf_bootloader_wdt: WDT is not enabled
00> <debug> app: in weak nrf_dfu_init_user
00> <debug> app: timer_stop (0x20000024)
00> <debug> app: timer_activate (0x20000024)
00> <info> app: Entering DFU mode.
00> <debug> app: Initializing transports (found: 1)
00> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init()
00> <debug> nrf_dfu_serial_uart: serial_dfu_transport_init() completed
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
00> <debug> app: Enter main loop
00> <error> app: Received an error: 0x00000004!

I did a few more tests where I changed RX_PIN_NUMBER to 8, 9, 10, 11, 12, 13. The same error occurs for pin 9, 10, 11 but not for the others. My challenge is in my board the pin 11 is used as RX and is interfaced with another board (cannot change this pin assignment). So either the same pin number is used for some other purpose in the bootloader program, although I do not see that in the code. Or some special configuration has to be applied to configure this pin as UART_RX.

RE: Firmware Update over UART Interface

Hung Bui — Tue, 19 Jan 2021 15:43:18 GMT

Hi,

Please show the log you have on RTT viewer. Basically we need to know which function throwed the error and which error code.

Please try to test the secure bootloader debug project with no modification and list the steps you did for testing.

RE: Firmware Update over UART Interface

Jatala — Mon, 18 Jan 2021 21:28:37 GMT

Hi Hung,

Thanks. I tested the bootloader in debug mode and apparently the bootloader throws an error from the UART port, please see attached call-stack trace where I have marked the code lines in respective functions where failure is occurring.

I noticed that in sdk_config.h both UARTE and UART drivers are enabled, not sure if this is causing the error.

RE: Firmware Update over UART Interface

Hung Bui — Mon, 18 Jan 2021 08:24:42 GMT

Hi Jatala,

You can follow what we have in the _debug bootloader. For example here you have the project setting with 100kB of flash reserved for the bootloader:

RE: Firmware Update over UART Interface

Jatala — Fri, 15 Jan 2021 23:08:15 GMT

That is clear. To 'increase the allocated flash for bootloader', I need to change of the start address of the bootloader, but I do not see such a parameter in the project flash_placement.xml file. I also do not see any option in the SEGGER project options. Any idea how to go about it.

RE: Firmware Update over UART Interface

Hung Bui — Fri, 15 Jan 2021 17:32:30 GMT

I meant just do a DFU update, without trying to implement switching to DFU from application.

RE: Firmware Update over UART Interface

Jatala — Fri, 15 Jan 2021 15:09:28 GMT

Thanks for the insight. Please bear with me, this is my first attempt at this kind of task. By normal DFU update, do you mean without using the security keys?

RE: Firmware Update over UART Interface

Hung Bui — Fri, 15 Jan 2021 14:51:38 GMT

Please try to follow my steps and made sure you can do a normal DFU udpate.

When you change optimization level to 0, the size of the bootloader getting bigger. So it won't fit into the current setting of the flash size and location.
You would need to move it down in flash and extend the size of the bootloader. Please have a look at the project configuration to increase the allocated flash for bootloader.

RE: Firmware Update over UART Interface

Jatala — Fri, 15 Jan 2021 14:15:17 GMT

- When I set the optimization level to zero, for debugging the bootloader, I get the following errors:

../SEGGER Embedded Studio for ARM 4.52c/gcc/arm-none-eabi/bin/ld: error: .text is too large to fit in FLASH memory segment
../SEGGER Embedded Studio for ARM 4.52c/gcc/arm-none-eabi/bin/ld: error: .dfu_trans is too large to fit in FLASH memory segment
../SEGGER Embedded Studio for ARM 4.52c/gcc/arm-none-eabi/bin/ld: error: .nrf_balloc is too large to fit in FLASH memory segment
../SEGGER Embedded Studio for ARM 4.52c/gcc/arm-none-eabi/bin/ld: error: .fs_data is too large to fit in FLASH memory segment
../SEGGER Embedded Studio for ARM 4.52c/gcc/arm-none-eabi/bin/ld: error: .rodata is too large to fit in FLASH memory segment
../SEGGER Embedded Studio for ARM 4.52c/gcc/arm-none-eabi/bin/ld: error: .data is too large to fit in FLASH memory segment
../SEGGER Embedded Studio for ARM 4.52c/gcc/arm-none-eabi/bin/ld: error: section .tdata overlaps absolute placed section .mbr_params_page

For optimization level > 0, some break points show message no code for breakpoint. Anyway I noticed that the bootloader repeatedly enters and exits the main() function. Not sure if it is normal behavior?

- From your tutorial, I know how to create the bootloader setttings file. But I must say I still struggling to comprehend the complete sequence to flash the bootloader, and the application.

RE: Firmware Update over UART Interface

Hung Bui — Fri, 15 Jan 2021 08:58:36 GMT

Please try debugging the bootloader, you can put a breakpoint in dfu_enter_check() in nrf_bootloader.c It's where the bootloader check if it would need to enter DFU mode or not.

You may need to compile the bootloader in debug mode (no optimization) to be able to put breakpoint and step in the code of the bootloader.

I assume that you have tested the functionality of the bootloader (DFU update) and also know how to create bootloader settting etc.

Please also try testing that you can enter the bootloader by holding a button when you reset.