I downloaded v3.1 from freescale's web site, as well as P&E's hardware device drivers. I have a P&E Coldfire 'LV' cable and a Dell Optiplex PC with Windows XP Pro. I have used this cable successfully to debug many CF processors using SDS (now WindRiver) SingleStep, including MCF5206e and MCF5249, so I'm pretty sure my PC, parallel port, and BDM. Foreword This document is a supplement and revision of AN4379 Freescale USB Mass Storage Device Bootloader written by dereksnell in 2011. The original version was programmed with CW for Flexis JM/ColdFire MCF522XX/Kinetis K60. It has not been updated for 2 years.
Introduction: Freescale FRDM-K64F: USB Communication
The Freescale K64F has features that make it ideal for controlling robot movement. For semi-autonomous operation, the accelerometers would allow one to do some dead reckoning and the magnetometer would allow for some absolute reference to improve the accuracy. It is not an ideal solution, but would be great for a fun robot.
But my first thought was to make a two wheeled robot (like a mini Segway). The accelerometers would be part of a closed loop system to allow the robot to balance. This robot would not be autonomous, but would be steered by a human. This project would not be simple, I am sure Dean Kamen spent many hours perfecting the Segway.
A first step in this project would be establishing a communication channel for controlling the robot. There are several options; Ethernet, several serial channels and USB. I even considered infrared. It is not native to to the FRDM-K64F, but I believe one could use the CMT (Carrier Modulation Timer) and some simple circuits to implement IR. But that is another project. I decided that USB would be a simple solution and investigated what was available. I found that Freescale has a USB stack that appears as a COM port. This Instructable shows how to use it in Windows, I believe it works in a similar way on other operating systems.
Step 1: What You Need
Freescale FRDM-K64F
USB with mini-USB end
The USB cable is not included in the FRDM-K64F package. It is necessary for development. This is the minimal amount of equipment one needs to experiment with the FRDM-K64F.
Step 2: Setting Up Your FRDM-K64F
Freescale has created a cloud based solution for development on the FRDM-K64F. And they have a clever technique for communicating with the device. Browsers can't directly access the hardware without a plugin. Each type of browser would need a plugin written for it. When one connects the FRDM-K64F development port to the PC, a virtual drive is created. Freescale has used the virtual drive to load code to the FRDM-K64F. I have seen that technique before (i.e. the Smoothieboard), but this is the first time I have seen it married it to a browser based development environment. When one builds code in the development environment, one can save it to the virtual drive.
I mention this because they have done another clever thing. That virtual drive has a link to the development web site. There are two mini-USB connectors on the board. The one to the left of the Ethernet connector looking toward the end of the board is the development port. Plug into that connector and into your computer. As stated, the USB device on the development port is set to appear as a mass storage device. It should pop up a window, if it doesn't pop up, track down the device. On Windows, it will be the next available drive letter. If one has a DVD and a CD drive, it would be 'F://'.
In that drive will be an 'mbed.htm' file. It has a link to the MBED web site. My device had the link below
I don't know if that code is unique to my device or if it encodes for all K64F devices. I think the latter is likely and the above link should work for everyone.
Step 3: Register on the MBED Web Site
When you click on the link, it will take you to the mbed.org login page.
Click on 'Signup'.
Then click on 'No, I haven't created an account before'.
Fill in the form with your information and click on 'Signup'.
Step 4: Open the Development Page
I have mixed feelings about the cloud paradigm, but uses like this seem pretty cool. Once you are logged in, click on the 'Compiler' link in the upper right corner. That will open the page where one can do Mbed development.
Step 5: Import USBSerial Program
I found more than one implementation of a USB stack. It seems to me that for Windows, the one I am using had the lowest barrier for success. There is a default 'Hello World' app that supposedly runs on the USB. But it doesn't work on Windows unless you run an executable file. This implementation requires no executable, it uses the normal 'inf' file that defines most USB devices. Here is the link to the USB stack I found useful.
Go to the page at the above link.
Go down to and click the button that says 'Import Program'.
Go back to the Development window.
Select 'Update all libraries to latest revision' and click on 'Import'
Step 6: Compile USBSerial Program
Select the newly imported program.
Click on the 'Compile' button.
Drivers Freescale Port Devices Scanner
When the compile completes a Open/Save box pops up.
Choose 'Save'.
In the following window choose the MBED drive. That will load the program into the K64F program memory. The unit will reset and the program will run.
Step 7: Getting the USB COM Port
As stated before there are two USB ports on the K64F. The program will be using the port to the right of the Ethernet port. If you plug into that port chances are you will get an unknown device in the Device Manager. The USBSerial page describes a way to solve the unknown device. I have attached the 'serial.inf' file they have offered. But in Windows 8 (and others I am sure) Microsoft has decided that we can't be trusted to use unsigned drivers. More likely they have decided that signed drivers make them money. In any case, the 'serial.inf' will not work in Windows 8 (and others). The Smoothie Board Project uses an Arm processor and I have found that their signed driver works. Unzip the attached file and follow the same procedure of browsing for the software, only this time go to the unzipped Smoothieware files.
Take note of the Com Port number that is created in the Device Manager. We will use it in the next step.
Attachments
- smoothieware-windows-signeddriver-v1.1.zip
Step 8: Talking to the Com Port
We need a terminal program to talk on the serial port. I use Putty for SSH, it is a good terminal program for this case as well.
After it is installed, open it up.
At the top type in the Com Port number from the previous step.
Set the speed to 115200.
Click on 'Open'
In the terminal window, one should see 'I am a virtual serial port' show up every second.
Step 9: Establishing Two Way Communications
The K64F is talking to the PC. Now we want to talk to the K64F. I have written a program to control the tri-color LEDs from the terminal.
Replace the main.cpp with the attached file.
Switch back to the Development port
Compile and save the file to MBED.
Switch to the other port.
The commands are of the form COLOR:value where COLOR is RED, GRN, or BLUE the value is 0-255.
The separating character is a colon (:).
We now have a USB communications channel for controlling our robot. Note that this package includes several other USB packages. The USBHID package is the one we would likely use if we were to write our own PC controller.
Be the First to Share
Recommendations
Microcontroller Contest
Automation Contest
Make it Glow Contest
- Introduction
- Toradex Standard Interfaces
- Configuration
- Non-standard Baud Rates
- RS-485
- Carrier Boards
- Computer on Modules
- Colibri VFxx
Serial port (UART) access from userspace on Linux is provided through TTY devices under /dev. Depending on the driver used to drive the UART, those devices can have different names such as /dev/ttymxc0 or /dev/ttyS0 among others. This article is very useful if you plan to use UART for communication with other devices - often using RS-232 or RS-485 - but if you just want to access the Linux terminal on the default debug UART, make sure to follow the first lessons from our Quickstart Guide or alternatively read the article Configuring Serial Port Debug Console (Linux/U-Boot).
Toradex Standard Interfaces
Toradex SoMs are pin-compatible within a family, as long as you use the default pin muxing from the Toradex Embedded Linux BSP. In this section, you will learn what UART interfaces are available on all Toradex SoMs within a family.
Keep in mind that each SoM may have additional UART interfaces that you can use at the tradeoff of breaking pin-compatibility. You will need to check how many UARTs are available on your specific SoM and modify the default pin muxing. Reading the SoM datasheet and the article Device Tree Customization are good starting points.
Apalis Family
The Apalis family has 4 pin-compatible UART interfaces.
| Toradex Name | Note |
|---|---|
| UART1 | debug (console) for the main OS (Cortex-A), with RTS/CTS, DTR/DSR and RI |
| UART2 | general-purpose, with RTS/CTS |
| UART3 | general-purpose |
| UART4 | general-purpose |
Colibri Family
The Colibri family has 3 pin-compatible UART interfaces.
| Toradex Name | Legacy Toradex Name | Note |
|---|---|---|
| UART_A | FF_UART | debug (console) for the main OS (Cortex-A), with RTS/CTS, DTR/DSR and RI |
| UART_B | BT_UART | general-purpose, with RTS/CTS |
| UART_C | STD_UART | general-purpose |
Verdin Family
The Verdin family has 4 pin-compatible UART interfaces. Three of them have RX and TX signals in Always Compatible pins, and the fourth has RX and TX signals on Reserved pins.
| Toradex Name | Always Compatible Pins | Reserved Pins | Note |
|---|---|---|---|
| UART_1 | RX and TX | RTS and CTS | general-purpose |
| UART_2 | RX and TX | RTS and CTS | general-purpose |
| UART_3 | RX and TX | - | debug (console) for the main OS (Cortex-A) |
| UART_4 | - | RX and TX | debug for the real-time OS (Cortex-M) or general-purpose |
This section has information about how to configure and use the serial, including a sub-section for RS-485.
Command-line
From userspace, one can use the command line utility stty to configure the serial speed. Then the port can be treated as as a regular file:
C
Using C, use the struct termios to set the initial baud rate:
Standard Baud Rates
A fixed list of baud rates are pre-defined:
| Baud rate | Symbol |
|---|---|
| 921600 | B921600 |
| 460800 | B460800 |
| 230400 | B230400 |
| 115200 | B115200 |
| 57600 | B57600 |
| 38400 | B38400 |
| 19200 | B19200 |
| 9600 | B9600 |
| 4800 | B4800 |
| 2400 | B2400 |
| 1200 | B1200 |
Non-standard Baud Rates
Vybrid modules
With the following userspace C program one can configure UART custom baud rates:
Vybrid's UART baud rate depends on the main bus clock. Since the two modules are clocked differently, the modules expose a different minimum and maximum baud rate. The baud rates which can practically be used are as follows:
| Module | Min-baud | Max-baud |
|---|---|---|
| Colibri VF50 | 510 | 4M |
| Colibri VF61 | 640 | 5M |
RS-485
The Toradex Carrier Board implements RS-485 using a single transceiver in a half-duplex communication mode, which means that one medium is shared for transmitting and receiving data. The transceiver switches to transmit mode when the RTS signal is asserted (low active).
RS-485 defines the electrical characteristics of drivers and receivers for serial communication and supports bus topology. How RS-485 is exactly implemented depends on application and requirements. The RS-485 support has been tested using the configuration as found on Toradex Carrier Boards.
Our modules provide the following support:
Drivers Freescale Port Devices Terminal
i.MX 6, i.MX 6ULL and i.MX 7 Modules
The driver uses the RTS output to control a RS-485 transceiver (see below).
Tegra Modules
Due to hardware limitations, there is no RS-485 transceiver control support.
Vybrid, i.MX 8, i.MX 8X and i.MX 8M Mini Modules
The Vybrid, i.MX 8, i.MX 8X and i.MX 8M Mini UART block has built-in support for RS-485 auto RTS for controlling the direction of the RS-485 transceiver (see below).
Enabling RS-485 support
Enable the RS-485 feature by either using ioctl from userspace or using device tree properties.
Userspace
Enable the RS-485 using ioctl TIOCSRS485 from userspace is described in RS-485 Kernel Documentation.
On Toradex carrier boards the following flags should be used:
Note that neither i.MX6 nor Vybrid based modules evaluate the delay parameters. i.MX6 based modules do additionally not evaluate the logic level parameters.
Device Tree
Enable it in the device tree by setting linux,rs485-enabled-at-boot-time, rs485-rts-active-low and rs485-rx-during-tx property.
Note: Some kernel version do not support the device tree properties rs485-rts-active-low and rs485-rx-during-tx yet. However, having them specified is not harmful to older kernels. Due to different defaults, newer kernels require those properties for RS-485 operation on Toradex carrier boards.
Note: On Vybrids and i.MX8 CPUs rs485-rts-delay is not working due to lack of hardware support.
This section provides details about UARTs on Toradex carrier boards. Remember that our carrier boards are open source and you can check their implementation anytime, just browse on the corresponding product page.
Apalis Evaluation Board
The Apalis Evaluation carrier board does have three regular 9-pin male D-Sub serial connectors for UART1 (RS-232 on bottom X28), UART2 (RS-232 on top X28) and optionally UART2 (RS-422/485 on X55). The UART3 is routed to the IrDA transceiver X30 by default. To route it to the UART1 port instead proceed as follows:
- Remove jumpers X3 rows 38 and 39 and X6 rows 33 to 40 to break the default UART1 to lower 9-pin male D-Sub and UART3 to IrDA connection.
- Connect X2-38 to X7-39 and X2-39 to X7-36 to re-route the UART3_TXD and UART3_RXD MXM3 pins to the UART1 lower 9-pin male D-Sub serial connector.
The UART4 is routed to the mezzanine connector X38 by default. To route it to the UART2 port instead proceed as follows:
- Remove jumpers X3 rows 36 and 37 and X6 rows 29 to 32 to break the default UART2 to upper 9-pin male D-Sub and UART4 to mezzanine connection.
- Connect X2-36 to X7-32 and X2-37 to X7-29 to re-route the UART4_TXD and UART4_RXD MXM3 pins to the UART2 upper 9-pin male D-Sub serial connector.
UART1 can optionally be connected to an integrated FTDI USB-to-serial chip to conveniently access the debug console. Make sure J10 and J12 Pin 2 and 3 are each jumpered (USB) to route TXD/RXD to the FTDI chip. Then, a simple USB A-B cable is sufficient to get a serial console directly from a computer (through /dev/ttyUSB0 on Linux hosts).
Colibri Evaluation Board
The Colibri Evaluation carrier board does have two regular 9-pin male D-Sub serial connectors for UART_A (lower) and UART_B (upper). The UART_C is routed to the IR by default. To route it to the UART_A port instead proceed as follows:
- Remove jumpers X11 rows 2, 3, 10 and 11 to break the default UART_A to lower 9-pin male D-Sub and UART_C to IR connection.
- Connect X10-2 to X12-10 and X10-3 to X12-11 to re-route the UART_C_RXD and UART_C_TXD SODIMM pins to the UART_A lower 9-pin male D-Sub serial connector.
UART_A can optionally be connected to an integrated FTDI USB-to-serial chip to conveniently access the debug console. Make sure J17 and J19 Pin 2 and 3 are each jumpered (USB) to route TXD/RXD to the FTDI chip. Then, a simple USB A-B cable is sufficient to get a serial console directly from a computer (through /dev/ttyUSB0 on Linux hosts).
Dahlia Carrier Board
- UART_3 and UART_4 are available on the USB Type Micro-B port (X18), via the USB to serial converter FT4232HL. You can use a regular USB Type Micro-B to Type-A.
- It is possible to route those interfaces to the Primary Extension Header with Dahlia's assembly options. Consult the datasheet for more details.
- In addition, FTDI and GPIO functions of the FT4232HL are connected to the Verdin SoM via R293-R296, JP6 and JP7. Consult the datasheet for more details.
- UART_1 is available on the Primary Extension Header (X20), as +1.8V TTL signals.
- UART_2 is available on the Secondary Extension Header (X19), as +1.8V TTL signals.
Iris Carrier Board
- To use UART_A (FF_UART) on the Iris carrier board a regular 10 pin female IDC to 9-pin male D-Sub RS-232 serial cable adapter (e.g. as used for most former PC motherboards) on X13 is required.
- To use the UART_B (BT_UART) on the Iris carrier board one can use the same regular RS-232 serial adapter from X13 on X14 as the RXD/TXD and RTS/CTS pins share the same connector layout.
- To use UART_C (STD_UART) on the Iris carrier board one can use X14 pin 1 as UART_C_RXD and pin 7 as UART_C_TXD.
For more information, see also Iris Carrier Board Peripherals.
Ixora Carrier Board
- To use UART1 on the Ixora carrier board a regular 10 pin female IDC to 9-pin male D-Sub RS-232 serial cable adapter (e.g. as used for most former PC motherboards) on X22 is required.
- To use the UART2 on the Ixora carrier board one can use the same regular RS-232 serial adapter from X22 on X21 as the RXD/TXD and RTS/CTS pins share the same connector layout.
- To use UART3 on the Ixora carrier board one can use X21 pin 1 as UART3_RXD and pin 7 as UART3_TXD.
- UART4 is only available as TTL level on the extension connector X27.
Verdin Development Board
The Verdin Development Board exposes the four UART interfaces.
- UART_3 and UART_4 are available on the USB Type Micro-B port (X66), via the USB to serial converter FT4232HL. You can use a regular USB Type Micro-B to Type-A.
- In addition, FTDI and GPIO functions of the FT4232HL are connected to the Verdin SoM via the X67 jumper area.
- UART_1 is available on a regular 9-pin male D-Sub serial connector (X50), through a RS-485 transceiver. Read the datasheet for available hardware configuration via jumpers JP6, JP9 and JP10.
- UART_2 is available on a regular 9-pin male D-Sub serial connector (X51), through a RS-232 transceiver. Read the datasheet for available hardware configuration via jumpers JP12.
This section provides details about UARTs on Toradex Computer on Modules.
Apalis iMX6
| Toradex Name | NXP/Freescale Name | Device |
|---|---|---|
| UART1 | UART1 | /dev/ttymxc0 |
| UART2 | UART2 | /dev/ttymxc1 |
| UART3 | UART4 | /dev/ttymxc3 |
| UART4 | UART5 | /dev/ttymxc4 |
| - | UART3 | - |
Note: The i.MX6 UARTs can be switched between DTE and DCE mode. The Apalis iMX6 module's pin assignment is designed for DTE mode.
Note: For V1.0A modules the assignment is different. UART3 and UART4 are swapped. e.g. UART3 is implemented with the i.MX6 UART5. All RX/TX lines are swapped and the UARTs have to be used in DCE mode to get the RX/TX functionality on the correct pins.
Apalis iMX8
| Toradex Name | NXP/Freescale Name | Device |
|---|---|---|
| UART1 | LPUART1 | /dev/ttyLP1 |
| UART2 | LPUART3 | /dev/ttyLP3 |
| UART3 | LPUART0 | /dev/ttyLP0 |
| UART4 | LPUART2 | /dev/ttyLP2 |
Apalis iMX8X
| Toradex Name | NXP/Freescale Name | Device |
|---|---|---|
| UART1 | LPUART1 | /dev/ttyLP1 |
| UART2 | LPUART0 | /dev/ttyLP0 |
| UART3 | LPUART2 | /dev/ttyLP2 |
| UART4 | LPUART3 | /dev/ttyLP3 |
Apalis T30
| Toradex Name | NVIDIA Name | Device |
|---|---|---|
| UART1 | UART1/UARTA | /dev/ttyS0 |
| UART2 | UART4/UARTD | /dev/ttyHS3 |
| UART3 | UART2/UARTB | /dev/ttyHS1 |
| UART4 | UART3/UARTC | /dev/ttyHS2 |
| - | UART5/UARTE |
Apalis TK1
| Toradex Name | NVIDIA Name | Device | Note |
|---|---|---|---|
| UART1 | UART1/UARTA/UA3 | /dev/ttyS0 | RX/TX and RTS/CTS only |
| UART2 | UART2/UARTB/IR3/UB3 | /dev/ttyTHS1 | |
| UART3 | UART3/UARTC/UC3 | /dev/ttyTHS2 | |
| UART4 | UART4/UARTD/UD3 | /dev/ttyTHS3 | |
| - | 6x Kinetis K20 Companion MCU UARTs | - | not supported in regular Embedded Linux BSP |
Colibri iMX6
| Toradex Name | Legacy Toradex Name | NXP/Freescale Name | Device |
|---|---|---|---|
| UART_A | FF_UART | UART1 | /dev/ttymxc0 |
| UART_B | BT_UART | UART2 | /dev/ttymxc1 |
| UART_C | STD_UART | UART3 | /dev/ttymxc2 |
| - | - | UART4 | - |
| - | - | UART5 | - |
Note: The i.MX 6 UARTs can be switched between DTE and DCE mode. The Colibri iMX6 module's pin assignment is designed for DTE mode.
Colibri iMX6ULL
| Toradex Name | Legacy Toradex Name | NXP/Freescale Name | Device | Notes |
|---|---|---|---|---|
| UART_A | FF_UART | UART1 | /dev/ttymxc0 | |
| UART_B | BT_UART | UART2 | /dev/ttymxc1 | |
| UART_C | STD_UART | UART5 | /dev/ttymxc4 | |
| - | - | UART3 | - | |
| - | - | UART4 | - | |
| - | - | UART6 | - | |
| - | - | UART7 | - | |
| - | - | UART8 | - |
Note: The i.MX 6ULL UARTs can be switched between DTE and DCE mode. The Colibri iMX6ULL module's pin assignment is designed for DTE mode.
Colibri iMX7
| Toradex Name | Legacy Toradex Name | NXP/Freescale Name | Device | Notes |
|---|---|---|---|---|
| UART_A | FF_UART | UART1 | /dev/ttymxc0 | |
| UART_B | BT_UART | UART2 | /dev/ttymxc1 | FreeRTOS/Cortex-M4 default console |
| UART_C | STD_UART | UART3 | /dev/ttymxc2 | |
| - | - | UART4 | - | |
| - | - | UART5 | - | |
| - | - | UART6 | - | |
| - | - | UART7 | - |
Note: The i.MX 7 UARTs can be switched between DTE and DCE mode. The Colibri iMX7 module's pin assignment is designed for DTE mode.
Colibri iMX8X
| Toradex Name | NXP/Freescale Name | Device |
|---|---|---|
| UART_A | LPUART3 | /dev/ttyLP3 |
| UART_B | LPUART0 | /dev/ttyLP0 |
| UART_C | LPUART2 | /dev/ttyLP2 |
Colibri Txx
| Toradex Name | Legacy Toradex Name | NVIDIA Name | Device |
|---|---|---|---|
| UART_A | FF_UART | UART1 | /dev/ttyS0 |
| UART_B | BT_UART | UART4 | /dev/ttyHS3 |
| UART_C | STD_UART | UART2 | /dev/ttyHS1 |
| - | - | UART3 | |
| - | - | UART5 |
By default, the first serial port uses the compatible 8250 driver to show a serial console (since NVIDIA's HS driver does not support a serial console).
Resources used by serial port on T20 devices:
Colibri VFxx
Our Vybrid based modules provide UART access through a Vybrid specific LP UART serial driver. The driver currently supports baud rates from 600 Baud up to 921600 Baud and can handle RTS/CTS hardware flow control.
| Toradex Name | Legacy Toradex Name | NXP/Freescale Name | Device | RTS/CTS support | FIFO size |
|---|---|---|---|---|---|
| UART_A | FF_UART | UART0 | /dev/ttyLP0 | Yes | 16 |
| UART_B | BT_UART | UART2 | /dev/ttyLP2 | Yes | 8 |
| UART_C | STD_UART | UART1 | /dev/ttyLP1 | Yes (non-standard pinmux) | 16 |
| - | - | UART3 | /dev/ttyLP3 | No | 8 |
| - | - | UART4 | /dev/ttyLP4 | Yes (non-standard pinmux) | 8 |
Note: UART3 and UART4 are not enabled by default on our standard images and need device tree modifications to be enabled.
Especially on higher baud rates and the slower Colibri VF50, overruns (and hence loss of characters) can happen. Check the tty driver statistics if you are suffering from those issues:
To ensure that no character is lost, use hardware flow control signals such as RTS/CTS or lower baud rates.
Enabling/disabling DMA
The current driver has a weak DMA implementation, which can lead to lock ups, especially on the RX side. The non-DMA (PIO) mode is much more robust, and thanks to the hardware FIFO also quite efficient. The easiest way to disable the DMA mode is to overwrite the dma-names property (see also Device Tree Customization):
Releases after V2.5 Beta 1 have a kernel argument to enable/disable DMA. The DMA is by default disabled, to re-enable UART DMA use:
Verdin iMX8M Mini
UART devices available on Linux:
| Toradex Name | NXP Name | Device |
|---|---|---|
| UART_1 | UART1 | /dev/ttymxc1 |
| UART_2 | UART2 | /dev/ttymxc2 |
| UART_3 | UART3 | /dev/ttymxc0 |
UART devices available only for the Cortex-M4, unless you properly modify the device tree:
Note: The i.MX8M Mini UARTs can be switched between DTE and DCE mode. The Verdin standard data direction is designed for DTE mode - which means that the SoC is configured in DCE mode.
See also