Maxim Integrated UG6258 Maxim Bootloader Tools User Guide

Maxim Bootloader GUI Tool
Maxim Bootloader GUI Tool is a PC application that is capable of programming and configuring the target bootloader over “Bootloader Programmer” hardware as shown in the block diagram (Figure 7).

Figure 7. Block diagram of components.
This tool comes with MSDK installer and during the installation, the bootloader GUI tool is registered on the Start menu. The user needs to type “Maxim Bootloader Tools” in the Start menu and click it as shown in Figure 8.

Figure 8. Maxim bootloader tool on start menu.

System Requirements
This section lists required equipment, instructions, and required connections for the proper set up of test platform. You may have a different target EV kit. Please check your EV kit bootloader user guide to get the target device pin configuration.

• Maxim Bootloader Programmer (MAX32625-PICO2 HW)
• Target EV kit (for this case MAX32660-EVSYS is used)
• 2 USB Type-A to Micro-USB Type B cables
• Some female–female cables
• Windows® PC (Windows 10) machine
• The latest Maxim SDK version must be installed on the PC. For details of the installation process, refer to the Maxim Micro SDK Installation and Maintenance User Guide.

Figure 9. Components to test bootloader GUI tool.

Figure 10. The overall system required pin connections.

Figure 11. MAX32660 EVSYS pins.

Figure 12. Bootloader GUI tool test setup.

Maxim Bootloader Tool Usage

The main screen of the bootloader GUI tool is shown in Figure 13 Before communicating with the target, the bootloader programmer board needs to be configured in the following manner:

• Select Comport: This was created by the “Maxim Bootloader Programmer” interface.
• Bridge Mode: The interface that is required to communicate with the target.
• Click Connect button.

You should see “SUCCESS” on the right side for success case.

Figure 13. Maxim bootloader GUI tool.
After connecting to the adapter the system is ready to communicate with the bootloader for further operations. Commands that do not require parameter for the bootloader are added under “Test Commands” drop-down under Bootloader tab. See Figure 14.

Figure 14. Bootloader test command.

For a quick test, select a command and send it.

• Send: “Hard Reset then Send Enter Bootloader Command”
• Send: “Get Target PartNumber”
• Send: “Get Target Bootloader Version”

Each test command result and the bootloader response is printed on the right side as shown in Figure 15 so that please check right side to see command execution result.

Figure 15. Bootloader GUI tool running some bootloader test command.

The bootloader configuration parameters can get and set over the “Configuration” section. For more information about bootloader commands and configuration parameters, refer to target bootloader user guide.

Figure 16. Bootloader GUI tool reading bootloader configuration parameters.

To update the target firmware, use the “FW Update” section, To start firmware update:

• Click the Browse button and select image (.msbl or .bin file)
• Then, click the Load button.

Successful load results can be seen in Figure 17.

Figure 17. Bootloader GUI tool firmware loading.
If you have .bin and key file instead of .msbl (Maxim secure bootloader) you should use BIN tab, then select .bin file and provide the key file path.

As mentioned in the Maxim Bootloader Programmer section, the Interface Board tab is used to configure the adapter The BL0/1 pins are used to RESET and MFIO on the bootloader side. The “Interface Board” section provides a way to test and configure these pins.
For test purposes, you can configure GPIO, set the logic level to high or low, and read GPIO status.

Figure 18. Maxim bootloader tool testing and configuring bootloader programmer board.

Interface board settings:

• RESET Pin: To select RESET pin, which pin (BL0/1) will be connected to target RESET pin.
• MFIO Pin and Polarity: To select MFIO pin and polarity, which pin (BL0/1) will be used for target MFIO pin.
• UART to Target: There are two universal asynchronous receiver-transmitters (UARTs) on the host programmer board (UART0/2).
• Target I2C Address: The I2C address that is used between the Bootloader Programmer Board–Target I2C communication.

Bootloader Host Example

Maxim provides a platform-independent bootloader host programmer example project with source code to users, so that they easily and quickly port it on their system and communicate with the bootloader.
To be a reference, the platform-independent bootloader host code is ported on the MAX32665 SDK. The MAX32665 SDK has a “Bootloader Host” example project which is able to communicate with Maxim bootloader firmware.

System Requirement
This section lists required equipment, instructions, and required connections to the setup of EV kit properly. You may have a different target EV kit, check your EV kit bootloader user guide to get your target device pin configuration.

• MAX32665 EV kit
• Target EV kit (in this case, MAX32660-EVSYS is used)
• CMSIS-DAP debug adaptor (MAX32625-PICO EV kit)
• Three USB Type-A to Micro-USB Type B cables
• Some female–female cables
• Windows PC (Windows 10) machine
• The latest Maxim SDK version must be installed on the PC. For details on the installation process, refer to the Maxim Micro SDK Installation and Maintenance User Guide.

Pin connection and final setup screen:

Figure 19. Bootloader host example setup block diagram

Figure 20. Bootloader host example full setup.

To create, build, and load bootloader host programmer example, following are the steps.

Creating Bootloader Host Example Project

• Run the Eclipse MaximSDK desktop application.

Figure 21. Starting Eclipse on the start menu.

• Select the workspace folder that contains the demo example and click Launch. Note that it is best to choose a path that contains no spaces.

• Start the wizard by clicking File → New → Maxim Microcontrollers.
  Figure 22. New project wizard.
  

• Enter the Project name and click Next.
  Figure 23. Set project name.

• Select MAX32665 as the Chip Type, EvKit_V1 as board type, Bootloader Host example as the example type, and adapter type (CMSIS-DAP in here) in the Select Project Configuration window.

Figure 24. Select project configuration.

• Then, click the Finish button. The demo project is created.

Building and Loading an Example Project
To build the example project, right-click the project in Project Explorer and then click Build Project.

Figure 25. Build project.

After the building is complete, check that the build has completed successfully, as shown in Figure 26.

Figure 26. CDT build console output.
To load firmware on the board, right-click on the project and select Debug As → Debug Configuration, then select project and click the Debug button. The firmware is loaded in the MAX32665 device onto EV kit.

Figure 27. Loading binary on target EV kit.

Bootloader Host Example Menu
After preparing the setup, building Bootloader Host example then loading it on MAX32665 EV kit if you start to execute it, the menu (Figure 28) appears on the PC terminal side. It is an interactive example you can select to know which operation is executed. Select it by typing the number on the PC side keyboard.

Figure 28. Bootloader host programmer example console menu.
The host and target communication interface can be selected by the Select Interface menu. Individual bootloader test commands can be tested by the Bootloader Test menu.
The example project includes some test .msbl images for the MAX32660 and MAX32670. These binaries can be loaded on the MAX32660 or MAX32670 target.

Porting Guide
The bootloader host programmer source code is designed to be hardware- independent so it can be ported on any system. To demonstrate it, the source code is ported on the MAX32665 microcontroller.

Figure 29. Bootloader host programmer example folders.
The files under the bootloader folder are platform-independent bootloader host programmer source code. These files (bootloader/bootloader.*) can be used as it is. The platform-related functions need to be registered during the initialization function call (bl_init function).

Figure 30. Platform-independent bootloader layer initialization function.
The functions that need to be registered are as follows:

• read/write: I2C, SPI, or UART read-write functions.
• gpio_set: The function that can set or clear GPIO state.
• delay_ms: milisecond delay function.
• printf: It is the debug purpose function.

After initialization (calling bl_init function) the other interface functions in bootloader.h file can be called.

Appendix A: Bootloader Programmer Board Protocol
Maxim bootloader programmer protocol is inserted inside DAPLink firmware to make it work as a bridge for I2C/SPI and so that it is able to drive the predefined GPIO pins.
In idle mode, DAPLink firmware works in UART bridge mode, and the firmware checks data that gets from the PC side. If a magic command is received to the interface board firmware, it switches to bridge mode depending on the command.
The general bridge command format is as follows:
Magic (8 bytes) + Len (1 byte) + Group Code (1 byte) + Command (Len-1 bytes)
Magic word (8 bytes): DE EF AA 55 23 41 16 DC
Switch Mode Commands Detail

Table 1. Switch Mode Commands

Request and response packet format are listed in the following figures:

Figure 31. Request packet (from PC to interface board).

Figure 32. Response packet (from bootloader programmer board to PC).
On the switch-mode response command, the interface board sends its current status and firmware version.
RetVal is 4 bytes, 0 (zero) means SUCCESS nonzero means fail.
Request and response packet example is as follows:

• Request (hex): DE EF AA 55 23 41 16 DC 04 42 49 32 43
• response: 00 1A 00 00 00 00 Mode:1, Version:v0.0.2

GPIO Commands
There are two general-purpose GPIOs on the interface board. These GPIOs can be set, clear, or read.
Two GPIOs are managed by 1 byte, which means for each GPIO 4 bits are used to set/clear/configure or read.
7-4 bits of 1 byte are used for GPIO1.
0-3 bits of 1 byte are used for GPIO0.

 Table 2. GPIO Commands

GPIO padding can be:0: Set pad to high impedance, weak pullup
1: Set pad to open-drain with high impedance input buffer enabled
2: Set pad to open-drain with weak pullup
3: Set pad to high impedance, input buffer enabled
4: Set pad to normal drive mode for high and low output
5: Set pad to slow-drive mode, which is the normal mode with negative feedback to slow edge transitions
6: Set pad to flash drive mode, which is the normal mode with a transistor drive to drive fast high, and low
7: Set pad to weak pulldown mode
8: Set pad to open-source mode, transistor drive to high
9: Set pad to open-source with weak pulldown mode, transistor drive to high, weak pulldown to GND for low
Other values do not affect.
0x01| Set/Clear GPIOs
0x02| Get GPIOs status

Interface board response format (same for all bridge commands):

Figure 33. Adapter response for GPIO commands.

Data part does not exist for configure, set/clear response packet, it is 1 byte for getting the GPIO status command.
GPIO set/clear request packet should be as follows:

Figure 34. GPIO set/clear command request.

As mentioned earlier, each GPIO pin is managed by 4 bits; for set/clear case, if nibble is 0 it means clear and if it is 1 it means set. The 0x0F (15) means do not touch it, leave it as it is.

I2C/SPI Bridge Mode Packet Format
After the interface board switches to bridge mode for I2C or SPI, each request should be sent in the following format:

Figure 35. I2C/SPI read/write request packet.

• Each request should start with ‘S’ and end with ‘P’ character.
• After ‘S’, address byte (I2C address) should be provided The LSB bit of address indicates read or write, 0:Write, 1:Read.
• After address bytes, 2 bytes length should be sent (big-endian format).

The read and write commands are the same; to read data from the target bootloader the LSB bit of address byte should be set to 1; and for read command length bytes indicate the number of bytes that will be read from bootloader.
Response packet format:

Figure 36. I2C/SPI read/write response packet.

On response,

• Len is data len + 4 bytes (for RetVal),
• The RetVal is the number of data that read or write by adapter over I2C or SPI.
• Data section valid for read command, for write request this section does not exist on response packet.

UART Bridge Mode Packet Format
There is no protocol for UART bridge mode and the adapter directly sends and receives the data that it read over UART.

Trademarks
Windows is a registered trademark and registered service mark of Microsoft Corporation.

Revision History

REVISION NUMBER| REVISION DATE| DESCRIPTION| PAGES CHANGED
---|---|---|---
0| 10/21| Initial release| —
| | |

©2021 by Maxim Integrated Products, Inc. All rights reserved. Information in this publication concerning the devices, applications, or technology described is intended to suggest possible uses and may be superseded. MAXIM INTEGRATED PRODUCTS, INC. DOES NOT ASSUME LIABILITY FOR OR PROVIDE A REPRESENTATION OF ACCURACY OF THE INFORMATION, DEVICES, OR TECHNOLOGY DESCRIBED IN THIS DOCUMENT. MAXIM ALSO DOES NOT ASSUME LIABILITY FOR INTELLECTUAL PROPERTY INFRINGEMENT RELATED IN ANY MANNER TO USE OF INFORMATION, DEVICES, OR TECHNOLOGY DESCRIBED HEREIN OR OTHERWISE. The information contained within this document has been verified according to the general principles of electrical and mechanical engineering or registered trademarks of Maxim Integrated Products, Inc. All other product or service names are the property of their respective owners.
Maxim Integrated

Read User Manual Online (PDF format)

Download This Manual (PDF format)

Download this manual  >>