merliness wrote:
It is also possible with the SAM9G35?
That depends on your board. Also you question and terminology are vague. Sometimes I use a USB-to-serial adapter and connect a RS232 (UART) port on the target board with a USB port on the host PC. There are even USB-to-serial adapters that can connect directly to a UART at logic levels. So according to your terminology, is this debugging via UART or USB?
USB and UARTs have a few similarities, but are actually two very different things that an engineer or developer should know. USB is a peripheral
bus (just like PCI and ISA), whereas UART is a
device. When most people talk about USB, they are often referring to somekind of USB device or gadget, rather than the actual USB connection which provides the control and data pathway (plus power).
Does "debugging via UART" mean that you used a RS232 communications link between your target board and the host PC? Are you referring to the UART on your target board or on your host PC?
If you are you referring to the UART on your target board, then you're probably connected to the debug or console port of the board. You have no debugging capabilities while at91bootstrap and U-Boot are executing; once the Linux kernel is running then there is GDB.
If you are you referring to a USB connection on your host PC, then you might be thinking of an ICE, in-circuit emulator. Some USB ICE emulate a serial port to the host, while others are a unique USB device that require its USB device driver for the PC's OS. One of the popular ones is the Segger J-Link, and there's a low-cost version just for Atmel devices, the SAM-ICE. Of course you need to have a JTAG connector on your board for the ICE. An ICE is useful for boot and board startup issues; once the MMU is enabled and virtual memory is employed, the ICE is not as useful.
Sometimes (e.g. multi-threading, inter-processor communications issues) you have to avoid relying on intrusive debugging tools (e.g. breakpoints), and just fall back on
printk()s (in the kernel) and
printf()s (in user code). I've seen some elaborate schemes using a couple of global data variables to control the runtime output of debug messages. Usually you want to control which sections/functionality of the software is outputting, and also the depth or detail of reporting.
Code:
#if DEBUG
if (debugfunc == DBFUNC_FOO && debuglevel == DEBUGLEVEL_2) {
printk("foo: xxx\n");
}
#endif
Regards
Forum
