GUI elements
The GUI window of the MfgTool application consists of two types of panels. The panels on the left hand side (called device panels or panes) show the device(s) connected to the respective USB Hub and Port number. There may be one to four device panels depending on the value set to the PortMgrDlg entry in the UICfg.ini file. A single “Status Information” panel appears on the right side of the GUI window, and the two buttons at the bottom right of the UI dialog.
UI showing one device connected to the PC host in the idle state
Device panel
The device panel shows the PC hub and port numbers at the top of the pane to which the MCU bootloader device is connected.
The UI element “Drive(s)” is not applicable for MCU bootloader devices.
The next UI element shows the type of device connected in the idle state. The MCU bootloader device is connected in the USB-HID mode and the display shows ‘HID-compliant device’. When connected in the UART mode, the text shows the respective virtual COM port number along with the description of the device (as it appears in the Windows® OS device manager). While manufacturing (non-idle state), the same element shows the command in the execution. When MfgTool is complete, the command sequences succesfully. The element can be made to display text such as ‘Done’, which is discussed later on in this document. When the manufacturing process is halted by the user using the “Stop” button, the text reverts back to the device description. The example screenshot below shows four MCUs connected to four USB ports in the HID and CDC modes in the idle state.
UI showing four MCUs connected to the PC host in the idle state
The last two UI elements of the device pane are the progress bars that show the progress while manufacturing. The first element shows the progress of the current blhost command being executed, and the second element shows the overall progress to complete the execution of all the commands listed in the ucl2.xml file. The progress bar appears in three different colors. Blue color indicates that the manufacturing is in process, green color indicates that the manufacturing completed successfully, and red color indicates that an error occurred. The error information are logged into the Mfgtool.log file for decoding purposes.
Parent topic:GUI elements
Status information panel
The Status Information panel have three data points, Successful Operationsshows number of MCU bootloader devices successfully manufactured, Failed Operationsshows number of devices failed and Failure Rateshow the percentage failure.
The image below shows manufacturing in progress.
Manufacturing in progress
The image below shows that manufacturing completed successfully for one single device.
Manufacturing completed successfully
The image below shows an error has occurred during manufacturing of one single device.
Error occurred during manufacturing
Parent topic:GUI elements
Firmware update process
The chapter and subsections below describe the process of device manufacturing using the MfgTool application for the MCU bootloader devices.
MCU bootloader device identification
The MCU bootloader performs the active peripheral detection at device startup to connect to the host to carry out the firmware download operations. If the bootloader device is connected to the UART or the USB, the PC host operating system enumerates the device, either in the USB CDC mode (via the SDA port, subject to hardware support), or the USB-HID mode (not all MCUs have the USB support). The MfgTool can identify the device’s presence by comparing the active USB devices’ vendor and product identifiers (VID and PID) with the supported identifiers mentioned in the <CFG> tag of the ucl2.xml file. The MfgTool can connect and update up to four devices simultaneously. The tool supports devices connected to the USB ports either in the HID or CDC modes only. The tool does not support devices connected to the PC via non-USB ports, such as the RS232 ports.
The example of the CFG tag section in the ucl2.xml file contains all the possible identification parameters known at the time of the release of this version of the document:
<CFG>
<STATE name="Blhost" dev="KBL-CDC" vid="1366" pid="1015"/> <!--JLINK CDC-->
<STATE name="Blhost" dev="KBL-CDC" vid="0d28" pid="0204"/> <!--mBed CDC-->
<STATE name="Blhost" dev="KBL-CDC" vid="1357" pid="0707"/> <!--OpenSDK CDC-->
<STATE name="Blhost" dev="KBL-CDC" vid="1357" pid="0089"/> <!--OpenSDA CDC-->
<STATE name="Blhost" dev="KBL-CDC" vid="1a86" pid="7523"/> <!--CH340 CDC-->
<STATE name="Blhost" dev="KBL-CDC" vid="067b" pid="2303"/> <!--PL2303 CDC-->
<STATE name="Blhost" dev="KBL-HID" vid="15A2" pid="0073"/> <!--KBL USB-HID-->
</CFG>
The example lists all the possible parameters to save you the time to find them. In an actual use case, you should comment the configuration lines that they do not want to use the corresponding ports for manufacturing. All configuration lines in the CFG tag section are of the same priority. If the number of devices connected to the host is bigger than the number of panels you configured, only the first-enumerated devices are displayed in the panels and the left ones are ignored.
The below figure shows the Windows OS Device Manager showing one MCU bootloader device connected in the USB-HID mode and two devices connected in the USB CDC mode, accessible via serial COM ports 3 and 6.
Windows OS Device Manager showing MCUs connected in the USB-HID and UART modes
The figure below shows the corresponding 4-panel MfgTool user interface for the above-connected devices showing one device connected in the HID mode, two devices connected in the CDC mode, and the last panel displaying as “No device connected”.
4-panel UI with three devices connected
Note: See theMCU Bootloader Demo Applications User’s Guide (document ID MBOOTDEMOUG) available at www.nxp.com/MCUBOOT page for instructions on how to connect the target platform MCU.
Parent topic:Firmware update process
Sequencing MCU bootloader commands
The MCU bootloader provides a set of commands to enable the host to find information about the device and to perform operations on the device’s flash memory such as read memory, write memory, erase memory, get or set properties, etc. The list of commands and properties supported by the MCU bootloader are documented in the MCU Bootloader Reference Manual.
The blhost tool is the NXP implementation of Windows OS PC host tool that communicates with MCU bootloader device connected to host via UART or USB-HID interface. The blhost tool is command line driven, the bootloader command and its parameters are passed on the command line and by issuing a sequence of commands full firmware update on the device can be achieved. For complete documentation and usage of blhost, see the blhost User’s Guide (document ID MCUBLHOSTUG) available at www.nxp.com/MCUBOOT.
MfgTool support for the MCU bootloader device is limited to identifying the device’s presence, and using blhost as its backend to send commands to the MCU bootloader device. To complete manufacturing the device, the MfgTool expects the blhost commands and parameters to appear in the body for each CMD listed in the ucl2.xml file, such as:
<CMD state="Blhost" type="blhost" body="flash-erase-region 0xA000 0x800">Flash Erase Region</CMD>
<CMD state="Blhost" type="blhost" body="read-memory 0xA000 0x800">Read Memory</CMD>
<CMD state="Blhost" type="blhost" body="write-memory 0xA000
\"Profiles\\Kinetis Bootloader\\OS Firmware\\files\\simple.bin\"">Write Memory</CMD>
<CMD state="Blhost" type="blhost" body="read-memory 0xA000 0x800">Read Memory</CMD>
The MfgTool cannot send any command to the bootloader directly, and instead uses blhost.exefor that purpose. The MfgTool does not decide what command to send, so the ucl2.xml should be crafted with the commands and its parameters needed to send to the device.
Each blhost command appears with separate <CMD> tag. The state and type indicates bootstrap operation using blhost. The actual blhost command line arguments goes with the bodytag.
Example:
<CMD state="Blhost" type="blhost" body="write-memory 0x0 demo.bin">Write Memory</CMD>
In the above example, blhost is invoked for write-memory command with 0x0 and demo.bin as two arguments; 0x0 is the start address location to write the contents of the file demo.bin.
Note: The default location where MfgTool locates the demo.bin is the folder where the MfgTool.exe is placed, i.e., “bin\tools\mfgtools-rel”. The complete path to demo.bin should be specified in the argument if demo.bin is placed elsewhere in the directory structure. For example: <CMD state="Blhost" type="blhost" body="write-memory 0xA000 \"Profiles\\Kinetis Bootloader\\OS Firmware\\files\\demo.bin\"">Write BIN to A000</CMD>
The last section of the <CMD> tag is the description text that will appear on MfgTool GUI when MfgTool is invoking the command and collecting its response. In the given example, “Write Memory” appears on the GUI.
The ucl2.xml does not need to specify the arguments needed for the type of connection such as –port or –usb, which is only necessary when using blhost in standalone mode. The MfgTool automatically provides the type of connection arguments to blhost.exe depending on the type of connection.
The MfgTool collects the device’s response that blhost outputs on the stdout, logs the response to MfgTool.log file, and inspects the results, reporting any error on the UI.
Parent topic:Firmware update process
Example ucl2.xml files
This section provides the typical ucl2.xml file content and shows how the different types of image files can be sent to the blhost using different commands, such as write-memory, flash-image, and receive-sb-file.
This is an example of a binary format file passed in an argument for the write-memory-command:
<CMD state="Blhost" type="blhost" timeout="5000" body="flash-erase-region 0xA000 0x800">Flash Erase Region</CMD>
<CMD state="Blhost" type="blhost" body="write-memory 0xA000
\"Profiles\\Kinetis Bootloader\\OS Firmware\\files\\demo.bin\"">Write Memory</CMD>
<CMD state="Blhost" type="blhost" body="Update Completed!">Done</CMD>
These are the examples of the srec and hex format files passed with the flash-image command:
<CMD state="Blhost" type="blhost" timeout="5000" body="flash-image
\"Profiles\\Kinetis Bootloader\\OS Firmware\\files\\simple.hex\" erase">Flash Image</CMD>
<CMD state="Blhost" type="blhost" body="Update Completed!">Done</CMD>
<CMD state="Blhost" type="blhost" timeout="5000" body="flash-image
\"Profiles\\Kinetis Bootloader\\OS Firmware\\files\\simple.srec\" erase">Flash Image</CMD>
<CMD state="Blhost" type="blhost" body="Update Completed!">Done</CMD>
These is an examples of a SB (Secure Binary) file passed in an argument for the receive-sb-file command:
<CMD state="Blhost" type="blhost" timeout="5000" body="receive-sb-file
\"Profiles\\Kinetis Bootloader\\OS Firmware\\files\\simple.sb\"">Receive SB File</CMD>
<CMD state="Blhost" type="blhost" body="Update Completed!">Done</CMD>
Parent topic:Firmware update process
Manufacturing process
This section shows how to execute the MfgTool for the MCU device manufacturing. The key to the MCU bootloader manufacturing with the MfgTool is to have the ucl2.xml file completed with all needed commands that are necessary to successfully program the device in a sequence.
The typical setup during manufacturing is shown in the image below with four devices connected to four USB ports to the PC running the MfgTool application.
Typical setup at manufacturing
The manufacturing process begins when the operator launches the MfgTool application and clicks the Start button.
The MfgTool provides the UI to show the device update progress for each device connected to the PC. The UI also shows the description text that appears in the ucl2.xml file for the command that is in execution. To indicate the end of programming for a device, a dummy command can be placed at the end of the ucl2.xml file with the text “Done” to conveniently identify the completion of the update so that you know when to switch to the new blank device. The example dummy command to indicate the completion of the update looks like this:
<CMD state="Blhost" type="blhost" body="Update Complete!">Done</CMD>
The MfgTool is in a continuous update mode until it is stopped by the user by pressing the “Stop” button. No user interaction is necessary on the UI when the “Start” button is pressed, except for pulling off the manufactured device when complete and connecting to the new blank device.
Parent topic:Firmware update process
Parent topic:GUI elements