This VI performs a software update from sd card.

A application that was built to boot from ProgDongle can be downloaded from the templates page.

The vi ZB.fimware.update.vi (since 4.1.1) can be executed from any position in the Application (FDM and compiled). The vi executes the following steps.

1. A reset is executed.
2. The device boots into the boot loader application
3. If a display is provided Messages about the update progress are displayed.
4. The boot loader application looks for a *.zfu file in the root directory.
5. The following points are checked before the update starts:
   1. Is there exactly one *.zfu file in the root directory?
   2. Is there a *.ldr file with the same name in the same directory?
   3. Does the size in the zfu file match the size of the loader file?
   4. Does the check sum in the zfu file match the calculated check sum of the loader file?
   5. Does the target in the zfu file match the target the boot loader was built for?
6. If all points above are ok, the ldr file is flashed into the boot flash.
7. A reset is executed
8. The flashed application is started

If no display refnum is wired to the vi, the firmware update is performed without display.

When building a standalone file with Zbrain SDK 4.1.1 or later two files are generated. The loader file (*.ldr) and a Zbrain SDK firmware update definition file (*.zfu).
The zfu file consists of a set of parameters that influence the firmware update process. It is automatically generated when creating a loader file.

###################################
# Firmware update definition file
###################################
name=FDMinterpreter
target=ZMC
size=001E3E56
chksum=00EF
deletme=0
waitbeforereset=15

• name This name is displayed during the update process.
• target The target name must match the target to update.
• chksum The check sum must match the check sum built over the loader file.
• size The size must match the size of the loader file in bytes.
• deletme If this parameter is 1 the zfu file will be deleted after the update. This can be used to prevent from repeatedly flashing the same update.
• waitbeforereset The target waits for the given seconds before resetting the board after the update. No reset is issued (reset or power cycle must be initiated manually) when this parameter is 0.

Lines started with a # are ignored and can be used for comments

• All supported interfaces can be used to bring the update onto the target.
• The loader file is the same as the one flashed by SDK via JTAG.
• No additional tools or target definitions are needed. (only targets from 4.1.1 on will work)
• The way a Firmware update is initiated can be adapted to specific needs because it is done in the Application.

• If the update process is interrupted by a reset or a power cycle, the firmware update will be corrupt. In this case the device needs to be reprogrammed manually via JTAG emulator. This limitation does not apply when starting the firmware update from ProgDongle.
• The flashed application is responsible to start the boot loader application. There is no by pass. It is crucial to test the firmware update functionality in new application versions before shipment.
• Older targets and SDKs are not supported.