USB as standard debug interface

In the past the typical debug backdoor was a RS232 interface. I have for instance a BlueWave multi-DSP VME board, which has beside the VME and an ethernet board an RS 232 for console output. The reason RS232 was chosen for this purpose is obvious, cheap, small, available on most PCs, easy to implement and in a way foolproof (or at least problems such as wrong pinout can be easily fixed).

I would expect that this role will is been taken over by USB now. The question is however, what type of service is used. Is there something established, or is this not necessary? I am aware that I can do a serial interface, jtag, etc. through USB, but this variety would counter the notion of "simply working without special SW" that the RS 232 provided.

What do you think?

Andreas

Reply to
acd
Loading thread data ...

See the thread "Do you still use "RS232" or something else?" starting

2011-01-14, Message-ID:

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

A simple approach is to install an FT232R or Prolific interface as the "debug backdoor" instead of the serial level shifter and continue to use the embedded chip's UART just as before. Or, keep the serial and just use a USB-serial dongle.

The only gotcha that I've seen to this is that WinXP might decide that it "recognizes" an FTDI/Prolific USB-serial connection as something other than a simple COM port if the port is active when the connection is plugged in. I have a board, for example, that's spitting out NMEA sentences over an FT232R that is *always* installed as a "Microsoft serial ballpoint" if the port is active when it's plugged in. The mouse cursor goes berserk. Much hilarity ensues. Do a 'net search for "USB serial ballpoint" and most of the hits are for this issue. @#$!$! Thank you, Microsoft.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Plus the constant annoyance of COM port numbers changing with the direction from which the wind is blowing. Today is COM739, tomorrow, who knows...

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]
Reply to
Roberto Waltman

USB Virtual Com (CDC device), HID debug device and MSD device are popular. Android has all three over the same USB link. Actually, plus one for GPS NEMA serial.

Reply to
linnix

I find that works nicely.

However, if you don't provide any identifying info (e.g. model string and serial number), dealing with more than one device at a time can be a hassle.

The same problem exists for non-USB serial ports under MS Windows. Any serial port that's receiving data as the OS boots is likely to be incorrectly detected as some sort of mouse.

This has been a problem in Windows for decades.

--
Grant Edwards               grant.b.edwards        Yow! A shapely CATHOLIC
                                  at               SCHOOLGIRL is FIDGETING
 Click to see the full signature
Reply to
Grant Edwards

Add those to applications which refuse to talk to anything other than COM1-COM4, and you get one more reason to switch to Linux.

--
Grant Edwards               grant.b.edwards        Yow! I'm young ... I'm
                                  at               HEALTHY ... I can HIKE
 Click to see the full signature
Reply to
Grant Edwards

I hope you don't seriously have COM739. I have COM23 from PIC and COM24 from Android. The PIC is running USB host VCP. My test system is something like:

Win XP PIC24 Android

+--------------+ +------------+ | PDK ICD |-----| ICD VCP |-------------\ | PDK VCP |-----| VCP | | | | +------------+ +----------+ | ADK VCP |------------------------| VCP VCP| | ADK MSD |------------------------| MSD | | ADK ICD |------------------------| ICD | +--------------+ +----------+

PDK: PIC24 development Kit ADK: Android development Kit

Reply to
linnix

Like many others, I use Linux for my own tinkering, but can not switch at work. Many unavoidable development tools run only on MS-Windows. (From my current short list, Analog Devices VisualDSP, FPGA dev tools, VisualStudio for WinCE, etc.)

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]
Reply to
Roberto Waltman

Not yet, but it is just a matter of time... ;)

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]
Reply to
Roberto Waltman

True but this is not the boot-time issue [1]. This instance is with a normally running Windows system in "equilibrium" to which a plain vanilla FTDI FT232R [2] is plugged. The bug (feature?!) hits if the serial->USB port is chattering away when Windows examines the device. In development we can just unplug the serial side until the driver is instantiated and a COM-port number assigned. Not so easy in the wild.

[1] I've had to deal with that joy as well. None of the recommended fixes (e.g., NoSerialMouse, fastdetect) were 100% reliable so we ended up putting relays on the incoming serial data lines that would only be shut once the XP board announced that it had completed booting. Feh. A terrible kludge but we did stop losing serial comms. [2] 'net searches indicate that this also occurs with the Prolific chips, so it's not likely to be an FTDI driver issue.

Sadly, yes.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

I use USB for programming, debugging, and console for all my projects. The FT232R is the chip of choice; not only do you get a standard serial port for your console (yay printf! :) but it has enough extra GPIO pins to reset the chip into programming mode and control it.

I've written up a spec for this for R8C chips, which covers some of the FT232R-specific details. The R8C chips use a serial protocol to download new firmware into them.

formatting link

I normally use DTR for reset and one of the GPIO (cbus) pins to control the boot mode when it comes out of reset, but it can be connected to another GPIO pin for standalone boards.

Reply to
DJ Delorie
[...]

You can Windows tell not to search for serial mice during boot.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

didn't observe this with FTDI VCP.

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

It's a Windows thing (surprise!) where devices that it "thinks" are different, even though they use the same interface chipset, may be assigned a new, unique COM port number.

It is possible to clean a given Windows box of the proliferation of virtual COM ports by removing the unused ports through the Device Manager. This is usually safe, since Windows will just assign a new number if one of the removed devices "comes back."

However, the Windows Device Manager will not normally permit the user to see devices that are not currently installed. In order to do so, it's necessary to set a new environmental variable (details are at ) or registry key (). Doing either and then turning on the Show Hidden Devices option allows one to see and then uninstall COM5 through COM739.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Yes, but will Windows listen to what it is told? Sadly, not always.

A Google search for turns up quite a few examples where the recommended fixes were not effective. I couldn't get it to work reliably with an XP Embedded project and had to make do with a hardware work-around.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

The thread seems to have degenerated into a complaint about VCP under Windows. I'm not sure what the result was.

It seems to me that you would have to have some sort of protocol for debugging regardless of using a serial port or a USB VCP. There are FTDI devices that directly support a JTAG output which is used in a number of JTAG adapters for various MCUs. Is that the sort of thing you are considering?

Rick

Reply to
rickman

I was thinking that the original question was about backdoor debugging. To me that means either in the "old" days using an emulator or now using the JTAG port. The use of serial over USB, USB direct, ethernet, CAN or whatever is just a way of communicating with the system. You may choose to add data that is useful for debugging but it's not the "backdoor" method.

All of my debugging is done with JTAG over USB via an FTDI device. Works pretty well and you can double up a serial port on the same device.

Dave.

Reply to
DaveN

In message , DaveN writes

Common sense at last.

Methods of debugging are

ICE (best method if available) Logic Analyser SWD (cortex) BDM JTAG serial monitor serial (manual debug) USB

The ICE and Logic Analyser are the only two that (should be) non intrusive and 100% full speed. These are the only real back door debuggers.

TO be honest JTAG is a kludge. BDM was better as it was purpose designed as Background Debug from the start as was the Cortex SWD

Serial monitors developed quite a way but require on chip resources and hence change the memory map and timing. They were quite popular for things like the 8051

USB on the other hand requires a LOT more working software and it can not debug itself it also requires far more of the system to be working. Most engineers can knock up an RS232 debug system in a few minutes from scratch. I doubt many if any can knock up a USB debug system from scratch.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

You can easily prevent this problem by disabling Plug and Play enumeration by modifying the INF files. FTDI provides documentation on how to do this.

Meindert

Reply to
Meindert Sprang

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.