MCU programming and debugging interface
The MT3620 exposes two dedicated UARTs and two control signals (reset and recovery) for use during device provisioning and recovery. In addition, a further dedicated UART and an SWD interface are optionally available for debugging.
The Azure Sphere PC software tools require the use of a USB-to-UART interface chip that exposes these interfaces to a PC in a way that allows the tools to recognize and interact with them. The Azure Sphere tools include support for loading an application over USB by using the Service UART and for updating the Azure Sphere OS by using the Recovery UART. The PC tools require the use of the Future Technology Devices International (FTDI) FT4232HQ UART-to-USB interface chip to expose the interfaces. Currently, the tools do not support other FTDI chips or interface chips from different manufacturers.
For development boards, this interface chip is usually on the same PCB as the MT3620. This approach is documented in the MT3620 reference development board (RDB) design. For a custom board or module that uses the MT3620, it may be appropriate to have the interface chip on a separate PCB, because the hardware is only required during manufacturing or servicing, enabling per-unit costs savings. This approach is documented in a stand-alone programming and debugging interface board design. Both such designs can be found in the Azure Sphere hardware designs repository on GitHub.
Overview of components
The following diagram provides an overview of the main components of the 4-port FTDI interface and their interconnections with the MT3620:
You may choose to use the FTDI chip and circuitry as a part of the same board as the MT3620 (for example, if you're building a development board) or in a separate interface board that sits between your MT3620 device and the PC.
To ensure compatibility with the PC tools, each of the four FTDI ports must be connected to the MT3620 as described in the following table:
|Function||FT4232HQ Pin Function (pin number)||MT3620 Pin Function (pin number)|
|Recovery UART, reset and recovery strapping pin||Port-D||DDBUS0 (48)||RECOVERY_RXD (134)|
|DDBUS1 (52)||RECOVERY_TXD (135)|
|DDBUS2 (53)||RECOVERY_CTS (136)|
|DDBUS3 (54)||RECOVERY_RTS (137)|
|DDBUS5 (57)||DEBUG_RTS (96)*|
|DDBUS6 (58)||SYSRST_N (125)|
|Service UART||Port-C||CDBUS0 (38)||SERVICE_RXD (129)|
|CDBUS1 (39)||SERVICE_TXD (127)|
|CDBUS2 (40)||SERVICE_CTS (130)|
|CDBUS3 (41)||SERVICE_RTS (128)|
SWD and reset
(Required for debugging real-time capable applications, otherwise optional)
|Port-B||BDBUS0 (26)||SWCLK||See SWD interface for details of SWD circuitry|
|BDBUS1 (27)||SWDIO out|
|BDBUS2 (28)||SWDIO in|
|BDBUS4 (30)||SWDIO direction|
|BDBUS5 (32)||SWD enable|
|BDBUS6 (33)||SYSRST_N (125)|
(optional, for use as advised by Microsoft)
|Port-A||ADBUS0 (16)||DEBUG_RXD (94)|
|ADBUS1 (17)||DEBUG_TXD (95)|
|ADBUS2 (18)||DEBUG_CTS (97)|
|ADBUS3 (19)||DEBUG_RTS (96)*|
*DEBUG_RTS is one of the MT3620's 'strapping pins' which, if pulled high during a chip reset, causes the chip to enter recovery mode. At all other times, this pin is the RTS pin of the Debug UART.
The following schematic shows the main components required to support the FT4232HQ chip:
See MT3620 reference board design for more information about the design files and schematics.
The 4.7K resistors in series with the reset line are included to avoid a short-circuit in the event a user presses the reset button (if included in the design).
When laying out the PCB, ensure that the differential pair, USB_P and USB_N, are routed parallel to each other to give a characteristic differential impedance of 90Ω.
The 33Ω resistors in series with the (optional) SWD lines are intended to reduce transients and should be placed close to the FT4232HQ.
The FTDI interface chip provides a set of pins that must be connected to a small EEPROM that is used to store manufacturer's details and a serial number. After board assembly, this information is programmed into the EEPROM over USB using a software tool provided by FTDI, as described later in FTDI FT_PROG Programming Tool.
The following EEPROM parts are compatible with the FTDI chip:
Note the use of the LC variant, which is compatible with a 3.3V supply. For internal development purposes, Microsoft has always used the 93LC56BT-I/OT part.
Connect the EEPROM to the FTDI chip as follows:
|EEPROM circuit||Connection to FTDI chip|
Recovery and Service UART interfaces
The Recovery and Service UART connections between the MT3620 and the FTDI require no special circuitry. However, note the cross-over of TXD and RXD, and CTS and RTS. The FTDI documentation describes pin 0 of each port as TXD and pin 1 as RXD. These definitions are relative to the FTDI chip; that is, pin 0 is an output and pin 1 is an input. Consequently, it is necessary to cross over the RXD and TXD connections to the MT3620 (and similarly for CTS and RTS). The following diagram illustrates this for the Service UART; use the same scheme for the Recovery UART as well:
Debug UART interface (optional)
Not all MT3620 modules expose this UART, and some expose only the output TXD signals.
The Debug UART provides additional debugging capabilities and is reserved for future use. If the UART is available, we recommend that you expose this interface, at least in development and lab environments, to enable easier debugging of any issues that arise.
As with the Recovery and Service UARTs, pay attention to the cross-over of TXD and RXD, and CTS and RTS:
SWD interface (optional)
Not all MT3620-based modules expose the SWD interface.
The MT3620 SWD interface is used to debug real-time capable applications. In contrast, debugging high-level applications uses the Service UART rather than SWD. If the device you are creating is intended for general software development (for example, a development board) or if the device will run real-time capable applications, then making SWD available is highly recommended. If the programming interface is intended only for programming devices in the factory, or if the device will not run any real-time capable applications, then connections to the SWD interface are not necessary.
Although FTDI chips are typically used to provide a bridge between UARTs and USB, the Azure Sphere programming and debugging interface uses additional circuitry based on a quad tristate buffer to allow the FTDI part to operate as a high-speed SWD interface.
The following table illustrates the required circuit and connection to the FTDI chip. Note that the SWDIO signal connects to the MT3620 pin 98 and SWCLK connects to pin 99.
|Tri-state buffer arrangement||FTDI Port-B connections|
USB activity LED (optional)
Although optional, a USB activity LED can be useful to indicate data transfer over the USB connection during normal operation. You can implement a USB activity LED in several ways. The following circuit is merely an example.
The circuit ANDs together the clock and data lines that connect the FT4232HQ to the EEPROM. Although not obvious, these two lines toggle when data is being sent and received over USB and therefore can be used to indicate USB activity. However, the on-time of the output from the AND gate is too short to illuminate an LED; therefore, this signal is used to drive a mono-stable circuit, which in turn drives the LED.
The on-time of the mono-stable circuit is set to 100ms, so that even short bursts of USB traffic will cause the LED to illuminate.
To help in programming the EEPROM, FTDI provides a free software tool called FT_PROG. The tool is available as both a Windows GUI application and as a command-line tool; both options are installed at the same time from the same package. Download the tool from the FTDI website and install it in the default location.
Using the FT_PROG GUI application
The Windows GUI version of the application is useful for reading and checking the state of the EEPROM information. You can also use it to change the information; however, we recommend the use of the command-line version of the tool to program the device, because you can program the complete configuration with a single command.
After you start the application, click the Scan button (with the magnifying glass icon) to read and display the current contents of the EEPROM.
If an Unknown Device dialog box appears, as in the following example, click OK until the application window displays the information correctly.
The following example shows the correct display:
See the FT_PROG documentation for more information about using the software.
Using the FT_PROG command-line tool
The command-line version of FT_PROG is the preferred method of programming the EEPROM, because it takes the name of a configuration file as a parameter and then programs the device with a single command.
The EEPROM configuration file is available in the azure-sphere-hardware-designs repo on GitHub. To program the EEPROM, you must use this file as is without modification, because the Azure Sphere PC tools look for the Product Description string and serial number and will fail if these values are changed. The serial number distinguishes an Azure Sphere programming interface from a stock FTDI device over USB.
Step-by-step instructions for EEPROM programming
To use the command-line version of FT_PROG to program the EEPROM for a four-port FTDI chip:
Install the FTDI tools in the default location: C:\Program Files(x86)\FTDI\FT_Prog\
Ensure that the MT3620 board is the only development board attached to the host PC.
Open a command prompt (for example, cmd.exe or an Azure Sphere Developer Command Prompt) and change to the folder where you saved the configuration file.
Type the following command:
"c:\Program Files (x86)\FTDI\FT_Prog\FT_Prog-CmdLine.exe" scan prog 0 MT3620_Standard_Interface.xml cycl 0
The tool should display:
Scanning for devices... Device 0: FT4232H, USB <-> Serial Converter Device 0 programmed successfully! Finished
To verify that programming was successful, enter:
"c:\Program Files (x86)\FTDI\FT_Prog\FT_Prog-CmdLine.exe" scan
The output should be:
Scanning for devices... Device 0: FT4232H, MT3620 Standard Interface, 984A8DD25A36