How can I get 1-10MB/s of debugging data to and from a dev board?

Question

Here's the fundamental problem I have: I'm looking at a dev board for, say, a TI/AD/Microchip microprocessor or DSP. This is long before a full product design; we're talking proof-of-concept work here. I want to send data from a PC to be processed by my firmware, or have my firmware send data to my PC. And I want the rate to be of the order of 1-10MB/s.

15+ years ago, 1-10MB/s would have been quite niche. kB/s would have been more usual, and the dev board would have had a DB9 connector on it. I could have just plugged a serial cable between the dev board and my PC, perhaps with a USB-to-serial converter, and read and write to COMX or /dev/ttySX.

However, this scheme has a number of limitations that are now starting to show up:

• I want MB/s, not kB/s.
• The absolute max UART rate a 100MHz device could manage is still only 0.7 MB/s. SPI on the other hand allows up to 3-4 MB/s.
• It's incredibly rare for PCs to come with serial ports now, so specialised adaptors are needed to interface with a PC eg. USB to serial cable.

But I'm stumped for what I could use to replace the old serial scheme. The main context for this question is sending serialised debugging data between vendor dev boards and a PC before design is finalised, so anything requiring secondary devices eg. Bluetooth isn't super useful. The µPs I typically work with are in the realm of TI's MSP430, Microchip's PIC32M*, and low power DSPs like the TI C55x or C674. Their dev boards might typically come with headers connected to SPI/I2C/UART peripherals.

Ethernet would require full implementation of a networking stack, which isn't really practical on the constrained DSPs or µPs I often work with. Furthermore most PCs only have one ethernet port, if at all, so you wouldn't be able to use it for wired networking.

Ground-up USB requires getting a vendor ID from a 3rd party, and reinventing all sorts of wheels at the driver and software level just to get data from one device to another.

Ideally I'd like to just be able to dump bytes in a peripheral register on my µP and drain it using Python on the PC or vice versa, using a cable most IT departments would have lying around, and get 1-10 MB/s. A bonus would be not having to poll every available port of whatever kind to find the device on a PC. Is this possible?

Answer 1

Modern successor for a RS232 communication port is supposed to be USB. However, people need to realize that if it is used for debug purposes, it must have some serious architecture support at system level, the port must have some internal bridges to uP registers and memories.

Starting in 2002, Intel has made an attempt to implement mandatory debug functions into open-standard EHCI controller. There was even some support for it, from Linux and Microsoft side, although, as I understand, all the effort had limited success.

With an advent of USB 3, the effort was resurrected, see USB 3.1 Debug Class Specifications.

Most recent Type-C connector also defines "Debug Accessory Mode", see pp 59-60. I believe there are several auxillary verions in the works on how to use the pins in alternate way, including JTAG functionality.

However, the old RS232 is not going away and refuses to die. The reason is that most uP and mini-OS are relying on venerable COM ports for many functions, and all Linux/Android flavors have a built-in debug support in kernel. And the UART circuitry/port is fairly simple to implement in silicon with very few resources. However, instead of placing bulky DB-9 connectors (which sometimes are bigger than the device itself) people are embedding a UART-USB converter on-board (typically of FTDI type), and use the miniature u-A/B USB connectors to attach to debug host, emulating COM port and using standard terminal software to access it.

Answer 2

I assume you are talking about a UART or serial interface, RS232 is an electrical and pin standard (simply defines what voltage levels a one and a zero are but not the state changes, protocols, speeds, etc).

Not sure where you got the 160000, you can easily go much faster than that with a cheap ftdi part. As well as fast jtag, swd, spi, i2c, etc with the same part (one with mpsse). (or roll your own protocol).

Depends on what your definition of PC is, desktops are dead, laptops are dying (all being replaced by tablets and phones), the primary PCs remaining are servers and they typically have at least one serial port as that is the primary display interface for booting/debugging, etc. But I know what you mean.

With the general lack of a need for RS232, usb to uart works just fine for a primary debug from a host/development pc against a target embedded board/system/chip.

For the ones you mentioned you can out run at least some of them with a usb uart solution so the MCU is the bottleneck there. Of the parts available you are more likely to find ones with uarts than with usb, certainly not ethernet. Your number one interface is uart, the ftdi parts and probably others make it easy to access any vendor specific or standardized protocols, or wiggle strap pins so you can use the uart to program the part in circuit. These vary from custom protocols (avr xmega), to stock spi while in reset (avr if I remember right), uart (msp430, a number of other brands/models), jtag, swd for the cortex-ms, all with a simple ftdi breakout board.

uart still dominates as generally having the lightest footprint on the bootloader. ethernet as you pointed out requires a stack, even cheating with UDP, you still need way more code than checking the receive buffer not empty bit and reading an already processed byte out of a uart peripheral. usb, if the mcu has it may be mostly done in hardware, so there are some that it is a lightweight thing but you often still have to enumerate yourself and respond to the host when requested, possibly more work than a dumbed down udp stack (the ones I have used it is other than the EZ-USB 8051).

You can get up to a MB/s with uart on some devices, but faster than that you are going to have to build a stack usb or ethernet or custom.

Answer 3

If the MCU is a Cortex-M you could look at Segger's J-Trace or J-Link and use it with RTT. RTT is a kind of a terminal-over-JTAG. The MCU places data in a RAM buffer and the debugger polls it. They advertise a speed of 3 MB/s.