USB as standard debug interface

On Fri, 18 Mar 2011 18:43:21 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2011-03-18, Rich Webb <bbew.ar@mapson.nozirev.ten> wrote:
>> On Fri, 18 Mar 2011 09:52:10 -0700 (PDT), acd <acd4usenet@lycos.de>
>> wrote:
>>
>>>In the past the typical debug backdoor was a RS232 interface.
>
>> 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.
>
>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.
>
>> 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 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.

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.

>> 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.
>
>This has been a problem in Windows for decades.

Sadly, yes.

-- 
Rich Webb     Norfolk, VA

acd <acd4usenet@lycos.de> writes:
> The question is however, what type of service is used.
> Is there something established, or is this not necessary?

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.

         http://www.delorie.com/electronics/gR8C/

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.

Grant Edwards wrote:

[...]

>> 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 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.

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

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

Roberto Waltman wrote:

>>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.
>
>Plus the constant annoyance of COM port numbers changing with the
>direction from which the wind is blowing. Today is COM739, tomorrow,
>who knows...

didn't observe this with FTDI VCP.

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

On Sat, 19 Mar 2011 15:29:54 +0100, Oliver Betz <OBetz@despammed.com>
wrote:

>Roberto Waltman wrote:
>
>>>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.
>>
>>Plus the constant annoyance of COM port numbers changing with the
>>direction from which the wind is blowing. Today is COM739, tomorrow,
>>who knows...
>
>didn't observe this with FTDI VCP.

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
<http://support.microsoft.com/kb/315539>) or registry key
(<http://www.pctools.com/guides/registry/detail/1107>). 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

On Sat, 19 Mar 2011 15:29:53 +0100, Oliver Betz <OBetz@despammed.com>
wrote:

>Grant Edwards wrote:
>
>[...]
>
>>> 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 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.
>
>You can Windows tell not to search for serial mice during boot.

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

A Google search for <Windows boot serial mouse "not work"> 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

On Mar 18, 12:52=A0pm, acd <acd4use...@lycos.de> wrote:
> 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

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

On 20/03/2011 17:30, rickman wrote:
> On Mar 18, 12:52 pm, acd<acd4use...@lycos.de>  wrote:
>> 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
>
> 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

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.

In message <Hyvhp.239532$tW4.119564@newsfe30.ams2>, DaveN
<DaveN@DaveN.com> writes
>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.

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     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Rich Webb" <bbew.ar@mapson.nozirev.ten> wrote in message
news:p647o6502mcuh9961hlh17ku8q7i75ckvi@4ax.com...
> 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.

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