Hey guys, does anyone know how you can debug through USB? I have a custom SAMA5D36 board, but failed to bring out the UART debug signals. I have JTAG and USB available. Unfortunately all the demos, and how-to's use the UART for debug.

It just seems silly to me that most embedded boards like RPi have a single point of contact for programming and debug through the USB, but the Xplained demo boards have three ports that have to be connected in order to get anywhere: USB, JTAG, and the debug UART.

bestboy4 wrote:Hey guys, does anyone know how you can debug through USB?

Depends on what you're trying to do.

bestboy4 wrote:It just seems silly to me that most embedded boards like RPi have a single point of contact for programming and debug through the USB,

You seem to be rationalizing your oversight/mistake with an observation that is inaccurate.
I don't know about microcontrollers, but the vast majority of (if not all) SoCs with MMUs have a serial port for the Linux console.
Many embedded devices can be hacked (or even "unbricked") by accessing a serial port, which is often a 3- or 4-pin header.
I've worked on various embedded boards using SoCs from Atmel, Freescale, Marvell, Allwinner (all ARM) and MStar (MIPS), and every one used a serial port and none required or supported a USB console as you claim.
As to the RPi, you may be confusing the use of a USB-serial-TTL adapter connected to the TTL serial port as a "USB connection".

bestboy4 wrote:but the Xplained demo boards have three ports that have to be connected in order to get anywhere: USB, JTAG, and the debug UART.

You seem to be overstating things.
IMO for real development, the DBGU port is essential for early development and booting, the JTAG is good to have for board bringup, and USB host and device ports are not necessary for debugging.

bestboy4 wrote:Hey guys, does anyone know how you can debug through USB? I have a custom SAMA5D36 board, but failed to bring out the UART debug signals. I have JTAG and USB available. Unfortunately all the demos, and how-to's use the UART for debug.

It just seems silly to me that most embedded boards like RPi have a single point of contact for programming and debug through the USB, but the Xplained demo boards have three ports that have to be connected in order to get anywhere: USB, JTAG, and the debug UART.

Seems to me that the most important port for debugging is the JTAG, since you that's the port you use for the in-circuit debugger. A UART is nice for printing "this is where I am!" statements out to a terminal, but if you want breakpoints, watches, single stepping, and the like, you need the JTAG port.

I hesitate to suggest these two methods because they are both a lot more involved than hooking an FTDI USB/serial chip to a spare UART. My advice: If you have a spare UART do another board turn and get the UART connected.

Or you could look into Percepio trace for Atmel Studio 6.2. I know this can be done with SAM3 and SAM4, but I do not know how many other ARMs support this. This may require SWD rather than JTAG.

If you have unused USB device hardware you can implement a CDC class (virtual com port) and redirect your "serial" debug data. But you need to create or find a suitable USB device stack. (If you manage to find right CDC descriptor set you will not need a driver with Windows.)

The USB solution can be a bit inconvenient, because when you stop your code you can lose your virtual com port connection. With each run you have to reconnect to your terminal program (AS6.2 Terminal, Tera Term, Putty, etc.).

Also:

Two different Xplained Pro boards I have used employ the Atmel EDBG chip which sends debug console data (as a virtual com port) through the same USB cable that is used for the JTAG/SWD data. The Atmel Studio 6.2 "Terminal" add-on seems to work fairly well to display this data.

Two different Xplained Pro boards I have used employ the Atmel EDBG chip which sends debug console data (as a virtual com port) through the same USB cable that is used for the JTAG/SWD data.

You're mischaracterizing this "virtual COM port". It has a USB connection to the host PC, but it also uses a UART on the SoC.
So you are back to the original problem of requiring access to a specific UART.