Note: This KBA is marked as deprecated, please refer to AN1086 for information on UART DFU
This article explains how to set up UART DFU in the latest BLE SDK 2.0.0 (build 1391). A full application note on DFU is going to be released later, the purpose of this quickstart guide is to help early adopters to get started with their DFU testing without having to wait for the official documentation.
** NOTE ** the issue with commander version is fixed in SDK version 18.104.22.168. If you already have this version installed then you can continue directly to next section Testing UART DFU.
The DFU image generation uses Simplicity Commander (commander for short) under the hood to create the update binaries. The copy of commander bundled under SDK 2.0.0-1391 is out-of-date (our mistake due to last minute changes before the release). To test UART DFU you will need to first update the commander to a new version.
Updating is simple: you should already have a fresh version of commander in your Studio installation tree, found in the following folder:
And the copy that is under the BLE stack directory is found in:
To manually update the commander used by BLE SDK, simply copy the whole “commander” folder from *\adapter_packs to *\bluetooth_2.0\bin. (You might want to rename the old version for example “commander_OLD” before the copy, just in case you would need to restore the original version at some point)
Once you have manually copied the new commander on top of the old one you can double-click the commander.exe and check that the new version is in use, see screenshot below.
The default version bundled in the 2.0.0-1391 SDK is 0.14.1 which is too old for UART DFU.
Simplest way to test UART DFU is with a development kit. It is assumed here that a BGM111 or BGM113 kit is used.
The wstk_bgapi example in the BGScript examples supports UART DFU out-of-the-box. When you build this example with BGTool you will see three *.ebl files generated. The largest one of the three (wstk_bgapi_full.ebl) is the one that you will need to perform UART DFU.
Quick test to get started with UART DFU:
Once you have created the update image (*_full.ebl), you can do the update using the UART DFU host example. The host example code is found in folder:
This folder includes a Makefile that allows you to build the program in Linux/ Cygwin/MinGW. The program takes three arguments: COM port number, baud rate and the name of the *.ebl file. For example:
uart-dfu.exe COM49 115200 wstk_bgapi_full.ebl
The WSTK on-board USB-to-UART uses fixed baud rate 115200 so the only need you need to change here is the COM port number.
NOTE: if you try changing the device name and it does not seem to have any effect on the module behavior it may be that your phone is using a cached version of the GATT database. Typically turning Bluetooth off and back on is enough to flush the phone GATT cache as a quick workaround.
The two lines in the project file (wstk_bgapi.bgproj) that are important for UART DFU are shown below (this is already done in the wstk_bgapi example, no need to edit the project file)
<!-- Firmware output file in EBL format --> <build ebl="wstk_bgapi"/> <bootloader type="uart" wstk="true"/>
In the <build> settings the ebl parameter defines the prefix that is used for naming the generated EBL files. (In previous SDK releases the setting was dfu, the file format was changed to EBL in 2.0)
The second line configures the bootloader to enable UART DFU. The wstk=”true” parameter is needed only when testing with a development kit. This is because the WSTK on-board USB-to-UART converted (VCOM) requires few additional GPIO signals to work. This setting is used only when testing UART DFU using the development kit and VCOM, otherwise it should be removed.
As a conclusion, to test UART DFU with BLE SDK 2.0.0-1391 you need to:
I've been trying to implement this new DFU process for the BLE SDK 2.0 for several days now without any success. I followed the above procedure exactly and built the support files for the WSTK dev kit to prove it out.
While I am able to run the uart-dfu.exe on my windows PC that I compiled with the gcc-arm, it says that it syncs with DFU OK, sends the entire .ebl file, and concludes with a "finish".
BUT, if i go now and use the commander.exe to read back the entire flash chip and save to a file, i compare (DIFF) this with the originally programmed .BIN file and I don't see an exact match.
The first 16 KBytes is the booloader and that part looks fine. Then the first 2048 bytes of the application space is read as all 0xFF values. The address this starts at is 0x4000 to 0x4800. This I presume is right after the bootloader space. Everything else on the flash pages is all correct and matches the .bin file. But the application will never boot because the entire first page is erased.
I also tried to write my own DFU uart code (following the pc uart code as a guideline) using an Em3588 chip as host talking with BGM111 as the NCP and the exact same thing happens. This is my target application, i need to be able to upgrade the BGM111 via UART DFU, and I need a solution very quickly as we need to program hundreds of blank BGM111 with some kind of basecode.
Can someone explain why this is happening or what I could be doing wrong? I feel there is a bug in the bootloader code or this has not been tested well by SiLabs..
can you please create a support ticket at following address: http://www.silabs.com/support
You can copy-paste the message you written here into the ticket, it clearly describes what the problem is. I haven't seen this kind of issue in my own UART DFU tests.
It would help if you can also attach following binaries to the support request:
- the original binary that you used to program the kit (before trying UART DFU)
- the *.ebl file that you used during testing
- the flash dump before / after the UART DFU
What is the arm-gcc toolchain version that you have installed under Simplicity Studio? It should be 4.9_2015q3 that is installed in:
I actually did put in a support ticket and they got back to me with a soluation. It turned out to be a problem with the Simplicity Stuiod install on windows, there was apparently another folder created with the same 'commander' program and some files did not get merged correctly resulting in corrupted .ebl/.bin builds I would presume.
I was told to basically delete/rename this folder (where i have my install)
After doing this, the bgbuild.exe reported that it then used the 'system path' for the missing utilities it needed. This change then resolved my problem and I hope this tip helps anyone else who is having similar troubles with the uart-dfu steps.
We have now released new version of the SDK 22.214.171.124 where the commander version is correct, no longer need to manually update the commander version.
The new version can be downloaded in Simplicity Studio by checking for updates and then installing BLE SDK 126.96.36.199 from the list of available stacks.
I'm using the BGM113 with the old DKBLE board and the uart_dfu is stuck at syncing with ID:01000020, if I press the reset button I get ID:020b00a0, ID:000100a0 and then loops on ID:01000020. As far as I checked on the uart_dfu code, it's waiting for ID:000000a0(gecko_evt_dfu_boot_id) but the device is sending ID:01000020(gecko_cmd_dfu_flash_set_address_id). Not sure if the uart_dfu is't catching the boot event or something else is wrong.
Any help is appreciated.
@gab_jump have you tried connecting to the BGM113 using BGTool? Are you able to see the boot event and the firmware version displayed in BGTool when you power up the board?
I assume that you are using a plain BGM113 module that is assembled to some custom hardware because you are using DKBLE board to communicate with the module. DKBLE is used here only as a USB-to-UART converter, right?
It might be better to create a new forum topic or a private support ticket for this case.
Hi! Yes, its working ok with BGTool, firmware version 0.9.2-459
"gecko_evt_system_boot major: 0 (0x0000) minor: 9 (0x0009) patch: 2 (0x0002) build: 459 (0x01cb) bootloader: 0 (0x0000) hw: 1 (0x0001)"
Yes, I used the BLE113 carrier board. I'm just using as a USB-UART as you said.
Alright, if you don't get any ideas with this new info, i'll open a new thread.
The firmware version 0.9.2-459 is so old that it does not even have UART DFU implemented! You should be running at least 1.0.2-755 or later. Our latest released SDK version is 188.8.131.52 and you should update to this version immediately before continuing any DFU tests.
@JaakkoV Oh, perfect! And is it possible to update without JTAG?
You can't update from 1.0.x or older versions to 2.0 using UART DFU only. It is required to first flash the unit with 2.0 firmware using ARM SWD debug interface so that the bootloader gets updated.
This is taken from the 2.0 SDK release notes:
"Version 2.0.0 is not backwards compatible with 1.0.x versions, meaning that an application written with 1.0.x SDK, will not work without modifications in 2.0.0 SDK and vice versa. Additionally, one cannot perform DFU, either over UART nor OTA, between the versions 1.0.x and 2.0.0."