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

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

See the thread "Do you still use "RS232" or something else?" starting
2011-01-14, Message-ID:
<news:gec0j65r3h4d8la23gfvj1cknu5n0erp4g@z1.oliverbetz.de>

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

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

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

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

--
Roberto Waltman

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

On Mar 18, 8:52=A0am, 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

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.

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.

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

-- 
Grant Edwards               grant.b.edwards        Yow! A shapely CATHOLIC
                                  at               SCHOOLGIRL is FIDGETING
                              gmail.com            inside my costume..

On 2011-03-18, Roberto Waltman <usenet@rwaltman.com> wrote:
> Rich Webb 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...

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
                              gmail.com            THRU CAPT GROGAN'S LUMBAR
                                                   REGIONS!

On Mar 18, 10:45=A0am, Grant Edwards <inva...@invalid.invalid> wrote:
> On 2011-03-18, Roberto Waltman <use...@rwaltman.com> wrote:
>
> > Rich Webb 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...

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

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

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 ]

linnix wrote:
>> > Plus the constant annoyance of COM port numbers changing with the
>> > direction from which the wind is blowing. Today is COM739, tomorrow,
>> > who knows...
>
>I hope you don't seriously have COM739. 

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

--
Roberto Waltman

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

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

"Roberto Waltman" <usenet@rwaltman.com> wrote in message
news:cs77o6d9s11bvdqa080684fedbdt6ivqf9@4ax.com...
> Plus the constant annoyance of COM port numbers changing with the
> direction from which the wind is blowing. Today is COM739, tomorrow,
> who knows...

If you include a unique serial number for the USB device, and the FT232R has
this provision, this problem does not exist. Once assigned, the COM port
number is linked to that device, no matter which USB port you plug it into.

Meindert

On Fri, 18 Mar 2011 09:52:10 -0700, acd 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?


Has anyone used the USB debug feature that is described in Appendix C of 
the EHCI spec?  It's been in the spec for over a decade now, but I only 
found out about it recently.

Brief description:  EHCI controllers have an optional "USB debug" mode in 
which the USB transceiver can be used to communicate with another 
similarly configured device, with an internal interface that's not much 
more complicated than that of a UART, the intention being to replace the 
function of a UART for debugging without needing a USB protocol stack.
The mode is optional, but seems to be supported on USB port 0 of all 
Intel devices with USB.

EHCI spec:
http://www.intel.com/technology/usb/ehcispec.htm

Example gizmo (to connect two USB debug ports):
http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083

There's info here showing that this mode is supported on devices from a 
number of manufacturers:
http://www.coreboot.org/EHCI_Debug_Port

Regards,
Allan

On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
>
> Methods of debugging are
>
> ICE  (best method if available)
> Logic Analyser
> SWD (cortex)
> BDM
> JTAG
> serial monitor
> serial  (manual debug)
> USB
>

You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-)

Great for debugging interrupt routines.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

"Meindert Sprang" wrote:
>"Roberto Waltman"  wrote
>> Plus the constant annoyance of COM port numbers changing with the
>> direction from which the wind is blowing. Today is COM739, tomorrow,
>> who knows...
>
>If you include a unique serial number for the USB device, and the FT232R has
>this provision, this problem does not exist. Once assigned, the COM port
>number is linked to that device, no matter which USB port you plug it into.

Thank you, I am aware of that. Can do it on my own devices (not
always,) but not with other products like the COTS USB to RS-232
dongle I used recently.

Searched for a while for a way to change the COM numbers
programmatically, but did not get far. Found a bunch of registry
entries that I could not delete. (on Windows XP)
--
Roberto Waltman

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

Rich Webb wrote:
>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.

I had trouble with an XP-Embeded project where the PC will attempt to
boot from the mouse, keyboard, etc. ignoring the only USB mass storage
device connected.
(Also ignoring any BIOS settings controlling enabled boot devices,
their order, etc.)
The workaround was also to add harware to disable some of the USB
ports and re-enable them under application control, well after the XP
boot process.
--
Roberto Waltman

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

In message <im7lrd$12k$1@news.eternal-september.org>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
>>
>> Methods of debugging are
>>
>> ICE  (best method if available)
>> Logic Analyser
>> SWD (cortex)
>> BDM
>> JTAG
>> serial monitor
>> serial  (manual debug)
>> USB
>>
>
>You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-)

true

>Great for debugging interrupt routines.

But not as good as an ICE or LA

The problem is you never really know what caused the LED to light.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Simon Clubley wrote:

> On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
>>
>> Methods of debugging are
>>
>> ICE  (best method if available)
>> Logic Analyser
>> SWD (cortex)
>> BDM
>> JTAG
>> serial monitor
>> serial  (manual debug)
>> USB
>>
> 
> You missed out LED (+ current limiting resistor) connected to a GPIO pin.
> :-)

That's a Logic Analyzer :)


	Mel.

In message <im7nnd$r8a$1@speranza.aioe.org>, Mel <mwilson@the-wire.com>
writes
>Simon Clubley wrote:
>
>> On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
>>>
>>> Methods of debugging are
>>>
>>> ICE  (best method if available)
>>> Logic Analyser
>>> SWD (cortex)
>>> BDM
>>> JTAG
>>> serial monitor
>>> serial  (manual debug)
>>> USB
>>>
>>
>> You missed out LED (+ current limiting resistor) connected to a GPIO pin.
>> :-)
>
>That's a Logic Analyzer :)

Luxury!  We had to debug in a darkened room with the off the MCU
watching the gates glow as they switched  working with a print out of
the assembled (wot's a compiler?) binary......

You tell that to the kids these days and they don't believe you.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Mon, 21 Mar 2011 10:54:03 +0100, "Meindert Sprang"
<ms@NOJUNKcustomORSPAMware.nl> wrote:

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

Interesting. Thanks!

Any reason that you're aware of (or bad things that may happen) if the
serial enumerator is de-selected for all virtual COM ports?

-- 
Rich Webb     Norfolk, VA

On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
>
>>You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-)
>
> true
>
>>Great for debugging interrupt routines.
>
> But not as good as an ICE or LA

On many platforms, ICE is useless for things like timeing measurement.
An LED (or better yet a few of them) works brilliantly for timing
measurements.

> The problem is you never really know what caused the LED to light.

While I suppose that's true in a theoretical sense, it's not true in a
practical sense.  In the real world (at least the one I work in), you
do know what cause the LED to light.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm EMOTIONAL
                                  at               now because I have
                              gmail.com            MERCHANDISING CLOUT!!

On 21/03/2011 15:47, Chris H wrote:
> In message<im7nnd$r8a$1@speranza.aioe.org>, Mel<mwilson@the-wire.com>
> writes
>> Simon Clubley wrote:
>>
>>> On 2011-03-21, Chris H<chris@phaedsys.org>  wrote:
>>>>
>>>> Methods of debugging are
>>>>
>>>> ICE  (best method if available)
>>>> Logic Analyser
>>>> SWD (cortex)
>>>> BDM
>>>> JTAG
>>>> serial monitor
>>>> serial  (manual debug)
>>>> USB
>>>>
>>>
>>> You missed out LED (+ current limiting resistor) connected to a GPIO pin.
>>> :-)
>>
>> That's a Logic Analyzer :)
>
> Luxury!  We had to debug in a darkened room with the off the MCU
> watching the gates glow as they switched  working with a print out of
> the assembled (wot's a compiler?) binary......
>
> You tell that to the kids these days and they don't believe you.
>

I remember debugging code on the ZX Spectrum by the buzzing sound of its 
power supply...

On 21/03/2011 15:03, Simon Clubley wrote:
> On 2011-03-21, Chris H<chris@phaedsys.org>  wrote:
>>
>> Methods of debugging are
>>
>> ICE  (best method if available)
>> Logic Analyser
>> SWD (cortex)
>> BDM
>> JTAG
>> serial monitor
>> serial  (manual debug)
>> USB
>>
>
> You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-)
>

And don't forget the burnt finger technique for hardware debugging.

 Chris H wrote:
>...
>Methods of debugging are
>ICE  (best method if available)

Saddly gone, in this world of ball-grid-arrays and surface-mounted
devices.

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

We do it when forced to. But still the simplicity of uart + RS-232 is
hard to beat.
My 2nd choice would be CAN, but it is not available everywhere and in
most cases cannot justify adding an externacl CAN controller to a
design.
--
Roberto Waltman

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

In message <im7oq5$57h$1@reader1.panix.com>, Grant Edwards
<invalid@invalid.invalid> writes
>On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
>>
>>>You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-)
>>
>> true
>>
>>>Great for debugging interrupt routines.
>>
>> But not as good as an ICE or LA
>
>On many platforms, ICE is useless for things like timeing measurement.
>An LED (or better yet a few of them) works brilliantly for timing
>measurements.

Assuming they are available for the part AFAIK the ONLY thing that is
any good for timing measurements are ICE or LA.


>> The problem is you never really know what caused the LED to light.
>
>While I suppose that's true in a theoretical sense, it's not true in a
>practical sense.  In the real world (at least the one I work in), you
>do know what cause the LED to light.

No you don't you only think you do.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <-dSdndhGOamK9hrQnZ2dnUVZ8umdnZ2d@lyse.net>, David Brown
<david@westcontrol.removethisbit.com> writes
>On 21/03/2011 15:47, Chris H wrote:
>> In message<im7nnd$r8a$1@speranza.aioe.org>, Mel<mwilson@the-wire.com>
>> writes
>>> Simon Clubley wrote:
>>>
>>>> On 2011-03-21, Chris H<chris@phaedsys.org>  wrote:
>>>>>
>>>>> Methods of debugging are
>>>>>
>>>>> ICE  (best method if available)
>>>>> Logic Analyser
>>>>> SWD (cortex)
>>>>> BDM
>>>>> JTAG
>>>>> serial monitor
>>>>> serial  (manual debug)
>>>>> USB
>>>>>
>>>>
>>>> You missed out LED (+ current limiting resistor) connected to a GPIO pin.
>>>> :-)
>>>
>>> That's a Logic Analyzer :)
>>
>> Luxury!  We had to debug in a darkened room with the off the MCU
>> watching the gates glow as they switched  working with a print out of
>> the assembled (wot's a compiler?) binary......
>>
>> You tell that to the kids these days and they don't believe you.
>>
>
>I remember debugging code on the ZX Spectrum by the buzzing sound of
>its power supply...

Happy days.......

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

>>> > Plus the constant annoyance of COM port numbers changing with the
>>> > direction from which the wind is blowing. Today is COM739, tomorrow,
>>> > who knows...
>>
>>I hope you don't seriously have COM739.
>
> Not yet, but it is just a matter of time... ;)

Yep.  We make products with COM ports on USB.  My dev computer is up to 
COM63.  It is just a matter of time when you hit some upper limit of who 
knows what.

JJS

On Mon, 21 Mar 2011 16:13:15 +0100, David Brown
<david@westcontrol.removethisbit.com> wrote:

><snip>
>I remember debugging code on the ZX Spectrum by the buzzing sound of its 
>power supply...

That goes back, though I can't recall doing that with my ZX81
(which I still have around, by the way.)  And not as far as
1975 when I would debug my Altair 8800 programs using a
nearby AM radio and using the tuning to select different
parts of the program during debugging.  (True, by the way.)

Jon

On Mon, 21 Mar 2011 16:13:56 +0100, David Brown
<david@westcontrol.removethisbit.com> wrote:

><snip>
>And don't forget the burnt finger technique for hardware debugging.

Used that.  Sadly, the damned 1488 was always VERY HOT.  Hard
to know, with that infernal thing.  At least the 1489 wasn't
so bad.

Jon

On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
> In message <im7oq5$57h$1@reader1.panix.com>, Grant Edwards
><invalid@invalid.invalid> writes
>>On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
>>>
>>>>You missed out LED (+ current limiting resistor) connected to a GPIO pin. :-)
>>>
>>> true
>>>
>>>>Great for debugging interrupt routines.
>>>
>>> But not as good as an ICE or LA
>>
>>On many platforms, ICE is useless for things like timeing measurement.
>>An LED (or better yet a few of them) works brilliantly for timing
>>measurements.
>
> Assuming they are available for the part AFAIK the ONLY thing that is
> any good for timing measurements are ICE or LA.
>
>
>>> The problem is you never really know what caused the LED to light.
>>
>>While I suppose that's true in a theoretical sense, it's not true in a
>>practical sense.  In the real world (at least the one I work in), you
>>do know what cause the LED to light.
>
> No you don't you only think you do.
>

Ok, it's time for me to learn something new because I don't know what you
are getting at.

Example setup: GPIO pin, with LED + resistor attached, is configured for
output and is set low by writing a zero to the appropriate bit in the
appropriate GPIO register at program startup.

The interrupt handler sets the appropriate bit in the GPIO register when
it's called, causing the LED to light and hence signalling that the
interrupt handler has been triggered.

Question: Why can't I assume that the interrupt handler has been
successfully triggered ?

If you are arguing that the code could scribble over the register causing
the LED to light at random, then I accept it's possible in theory, but
in practice, I have never seen a bug like that in my code.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 2011-03-21, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>>>> The problem is you never really know what caused the LED to light.
>>>
>>>While I suppose that's true in a theoretical sense, it's not true in a
>>>practical sense.  In the real world (at least the one I work in), you
>>>do know what cause the LED to light.
>>
>> No you don't you only think you do.
>>
>
> Ok, it's time for me to learn something new because I don't know what you
> are getting at.

Me neither.

> Example setup: GPIO pin, with LED + resistor attached, is configured
> for output and is set low by writing a zero to the appropriate bit in
> the appropriate GPIO register at program startup.
>
> The interrupt handler sets the appropriate bit in the GPIO register
> when it's called, causing the LED to light and hence signalling that
> the interrupt handler has been triggered.
>
> Question: Why can't I assume that the interrupt handler has been
> successfully triggered ?

I've been using that assumption for 30 years.  It's never been wrong
yet.

> If you are arguing that the code could scribble over the register
> causing the LED to light at random, then I accept it's possible in
> theory, but in practice, I have never seen a bug like that in my
> code.

Same here.

-- 
Grant Edwards               grant.b.edwards        Yow! over in west
                                  at               Philadelphia a puppy is
                              gmail.com            vomiting ...

In message <im8393$de5$1@news.eternal-september.org>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
>> In message <im7oq5$57h$1@reader1.panix.com>, Grant Edwards
>><invalid@invalid.invalid> writes
>>>On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
>>>>
>>>>>You missed out LED (+ current limiting resistor) connected to a
>>>>>GPIO pin. :-)
>>>>
>>>> true
>>>>
>>>>>Great for debugging interrupt routines.
>>>>
>>>> But not as good as an ICE or LA
>>>
>>>On many platforms, ICE is useless for things like timeing measurement.
>>>An LED (or better yet a few of them) works brilliantly for timing
>>>measurements.
>>
>> Assuming they are available for the part AFAIK the ONLY thing that is
>> any good for timing measurements are ICE or LA.
>>
>>
>>>> The problem is you never really know what caused the LED to light.
>>>
>>>While I suppose that's true in a theoretical sense, it's not true in a
>>>practical sense.  In the real world (at least the one I work in), you
>>>do know what cause the LED to light.
>>
>> No you don't you only think you do.
>>
>
>Ok, it's time for me to learn something new because I don't know what you
>are getting at.
>
>Example setup: GPIO pin, with LED + resistor attached, is configured for
>output and is set low by writing a zero to the appropriate bit in the
>appropriate GPIO register at program startup.
>
>The interrupt handler sets the appropriate bit in the GPIO register when
>it's called, causing the LED to light and hence signalling that the
>interrupt handler has been triggered.
>
>Question: Why can't I assume that the interrupt handler has been
>successfully triggered ?
>
>If you are arguing that the code could scribble over the register causing
>the LED to light at random, then I accept it's possible in theory, but
>in practice, I have never seen a bug like that in my code.

How would you know?

You have no real idea what actually caused the line to toggle nor the
events that lead up to it.

With a decent ICE you do know and you have the full trace and timings.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message <e92fo6tsbrsb98iiq9lj4248knjc5tefgf@4ax.com>, Jon Kirwan
<jonk@infinitefactors.org> writes
>On Mon, 21 Mar 2011 16:13:15 +0100, David Brown
><david@westcontrol.removethisbit.com> wrote:
>
>><snip>
>>I remember debugging code on the ZX Spectrum by the buzzing sound of its
>>power supply...
>
>That goes back, though I can't recall doing that with my ZX81
>(which I still have around, by the way.)  And not as far as
>1975 when I would debug my Altair 8800 programs using a
>nearby AM radio and using the tuning to select different
>parts of the program during debugging.  (True, by the way.)


I ended up with a Spectrum  with 3 parallel OS Standard, tweaked, one of
my own and a bank of ram I could download a modified on to... denounced
hardware switching.  Also drove a monitor (not a TV) and had a full size
keyboard + parallel ports, serial 2 Floppy drives and a decoder for
Prestel.....   in fact there was more auxiliary electronics than
original especially as surplus bits like the TV tuner had been removed

However that was about 30 years ago when I had time...... :-)

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 2011-03-21, Chris H <chris@phaedsys.org> wrote:

>>>>> The problem is you never really know what caused the LED to light.
>>>>
>>>>While I suppose that's true in a theoretical sense, it's not true in a
>>>>practical sense.  In the real world (at least the one I work in), you
>>>>do know what cause the LED to light.
>>>
>>> No you don't you only think you do.
>>>
>>
>>Ok, it's time for me to learn something new because I don't know what you
>>are getting at.
>>
>>Example setup: GPIO pin, with LED + resistor attached, is configured
>>for output and is set low by writing a zero to the appropriate bit in
>>the appropriate GPIO register at program startup.
>>
>>The interrupt handler sets the appropriate bit in the GPIO register
>>when it's called, causing the LED to light and hence signalling that
>>the interrupt handler has been triggered.
>>
>>Question: Why can't I assume that the interrupt handler has been
>>successfully triggered ?
>>
>>If you are arguing that the code could scribble over the register
>>causing the LED to light at random, then I accept it's possible in
>>theory, but in practice, I have never seen a bug like that in my code.
>
> How would you know?

Seriously?  You have no way to tell if your software is working other
than by looking at a trace from an ICE?

> You have no real idea what actually caused the line to toggle nor the
> events that lead up to it.

Actually, Yes, I do have a pretty good idea.

> With a decent ICE you do know and you have the full trace and
> timings.

Thats true, but it's pretty much a moot point.  None of the parts I've
used for the past 15+ years or so have had "decent ICE" availble.  The
68HC11 was the last part I used for which ICE with any tracing
capability was available. That was sometime around 1991.  I've used
probably a dozen or so parts with JTAG interfaces, but none of them
had any tracing or timing analysis capabilities.

The LED approach has always worked flawlessly for me, but I guess
YMMV.

-- 
Grant Edwards               grant.b.edwards        Yow! An Italian is COMBING
                                  at               his hair in suburban DES
                              gmail.com            MOINES!

In article <5l2fo6d2vtqafislgsb9equgr58sdtvbl0@4ax.com>, 
jonk@infinitefactors.org says...
> 
> On Mon, 21 Mar 2011 16:13:56 +0100, David Brown
> <david@westcontrol.removethisbit.com> wrote:
> 
> ><snip>
> >And don't forget the burnt finger technique for hardware debugging.
> 
> Used that.  Sadly, the damned 1488 was always VERY HOT.  Hard
> to know, with that infernal thing.  At least the 1489 wasn't
> so bad.

Ah the day many years ago when I debugged a faulty baud rate generator
as my finger slipped off the scope probe and left a layer of burnt SKIN
one the metal lid of the ceramic package. Yes that was the faulty device
along with burnt DNA to log who fixed the problem device.

Now that's what I call traceability!!

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

In article <im85qk$ejk$1@reader1.panix.com>, invalid@invalid.invalid 
says...
> 
> On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
> 
> >>>>> The problem is you never really know what caused the LED to light.
> >>>>
> >>>>While I suppose that's true in a theoretical sense, it's not true in a
> >>>>practical sense.  In the real world (at least the one I work in), you
> >>>>do know what cause the LED to light.
> >>>
> >>> No you don't you only think you do.
> >>>
> >>
> >>Ok, it's time for me to learn something new because I don't know what you
> >>are getting at.
> >>
> >>Example setup: GPIO pin, with LED + resistor attached, is configured
> >>for output and is set low by writing a zero to the appropriate bit in
> >>the appropriate GPIO register at program startup.
> >>
> >>The interrupt handler sets the appropriate bit in the GPIO register
> >>when it's called, causing the LED to light and hence signalling that
> >>the interrupt handler has been triggered.
> >>
> >>Question: Why can't I assume that the interrupt handler has been
> >>successfully triggered ?
> >>
> >>If you are arguing that the code could scribble over the register
> >>causing the LED to light at random, then I accept it's possible in
> >>theory, but in practice, I have never seen a bug like that in my code.
> >
> > How would you know?
> 
> Seriously?  You have no way to tell if your software is working other
> than by looking at a trace from an ICE?
> 
> > You have no real idea what actually caused the line to toggle nor the
> > events that lead up to it.
> 
> Actually, Yes, I do have a pretty good idea.
> 
> > With a decent ICE you do know and you have the full trace and
> > timings.
> 
> Thats true, but it's pretty much a moot point.  None of the parts I've
> used for the past 15+ years or so have had "decent ICE" availble.  The
> 68HC11 was the last part I used for which ICE with any tracing
> capability was available. That was sometime around 1991.  I've used
> probably a dozen or so parts with JTAG interfaces, but none of them
> had any tracing or timing analysis capabilities.

ICE came in various forms

Bond Out
Emulation
Pin moditoring

These days bond out is too expensive to do for the complexity of
the of the devices and would require special wafers to make larger
sized die to hold all the required bond out wires to look before and
after pipeline and caches. Let alone myriad of busses and multiple
cores. Anything beyond the simplest 16 bit mcro with EXTERNAL 
memory becomes difficult.

Emulation is even harder to do at hardware level.

Pin monitoring to detect what the processor is doing is pointless as 
many micros above 8 bit have all sorts of pipelining, even a few stages 
of bus bridges and buffering can make it difficult to determine what 
actually is happening to crete a useful trace buffer.

I have seen so few ICE systems (not JTAG/SWD/BDM) for over 10 years).
They were always expensive as the majority were special bond out or
emulation types in small volume runs.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

On 21/03/2011 18:19, Chris H wrote:
> In message<im8393$de5$1@news.eternal-september.org>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP>  writes
>> On 2011-03-21, Chris H<chris@phaedsys.org>  wrote:
>>> In message<im7oq5$57h$1@reader1.panix.com>, Grant Edwards
>>> <invalid@invalid.invalid>  writes
>>>> On 2011-03-21, Chris H<chris@phaedsys.org>  wrote:
>>>>>
>>>>>> You missed out LED (+ current limiting resistor) connected to a
>>>>>> GPIO pin. :-)
>>>>>
>>>>> true
>>>>>
>>>>>> Great for debugging interrupt routines.
>>>>>
>>>>> But not as good as an ICE or LA
>>>>
>>>> On many platforms, ICE is useless for things like timeing measurement.
>>>> An LED (or better yet a few of them) works brilliantly for timing
>>>> measurements.
>>>
>>> Assuming they are available for the part AFAIK the ONLY thing that is
>>> any good for timing measurements are ICE or LA.
>>>
>>>
>>>>> The problem is you never really know what caused the LED to light.
>>>>
>>>> While I suppose that's true in a theoretical sense, it's not true in a
>>>> practical sense.  In the real world (at least the one I work in), you
>>>> do know what cause the LED to light.
>>>
>>> No you don't you only think you do.
>>>
>>
>> Ok, it's time for me to learn something new because I don't know what you
>> are getting at.
>>
>> Example setup: GPIO pin, with LED + resistor attached, is configured for
>> output and is set low by writing a zero to the appropriate bit in the
>> appropriate GPIO register at program startup.
>>
>> The interrupt handler sets the appropriate bit in the GPIO register when
>> it's called, causing the LED to light and hence signalling that the
>> interrupt handler has been triggered.
>>
>> Question: Why can't I assume that the interrupt handler has been
>> successfully triggered ?
>>
>> If you are arguing that the code could scribble over the register causing
>> the LED to light at random, then I accept it's possible in theory, but
>> in practice, I have never seen a bug like that in my code.
>
> How would you know?
>
> You have no real idea what actually caused the line to toggle nor the
> events that lead up to it.
>
> With a decent ICE you do know and you have the full trace and timings.
>
>
As we're becoming pedants here, then Chris your assuming the ICE has no 
bugs and your using the subjective term "decent"!

You can only know for certain if the tools making the measurement are 
perfect in their operation and if they have zero effect on the system 
being measured.  As all tools are built with other imperfect tools and 
you can't possibly have zero effect then you can never know for absolute 
certain.

However bringing us back to reality with a bump, I see no problem with a 
LED on GPIO :-)

On Mar 21, 12:00=A0pm, "John Speth" <johnsp...@yahoo.com> wrote:
> >>> > Plus the constant annoyance of COM port numbers changing with the
> >>> > direction from which the wind is blowing. Today is COM739, tomorrow=
,
> >>> > who knows...
>
> >>I hope you don't seriously have COM739.
>
> > Not yet, but it is just a matter of time... ;)
>
> Yep. =A0We make products with COM ports on USB. =A0My dev computer is up =
to
> COM63. =A0It is just a matter of time when you hit some upper limit of wh=
o
> knows what.
>
> JJS

My Vista machine has COM256.  So clearly they can go pretty high.  Is
this really much different from IP addresses and such?  It's just a
number right?  The software that is stuck at COM1-COM4 are still
thinking they need to handle the interrupt and IO port.

Rick

On Mar 21, 10:19=A0am, Roberto Waltman <use...@rwaltman.com> wrote:
> "Meindert Sprang" wrote:
> >"Roberto Waltman" =A0wrote
> >> Plus the constant annoyance of COM port numbers changing with the
> >> direction from which the wind is blowing. Today is COM739, tomorrow,
> >> who knows...
>
> >If you include a unique serial number for the USB device, and the FT232R=
 has
> >this provision, this problem does not exist. Once assigned, the COM port
> >number is linked to that device, no matter which USB port you plug it in=
to.
>
> Thank you, I am aware of that. Can do it on my own devices (not
> always,) but not with other products like the COTS USB to RS-232
> dongle I used recently.
>
> Searched for a while for a way to change the COM numbers
> programmatically, but did not get far. Found a bunch of registry
> entries that I could not delete. (on Windows XP)

I find that if I change the com port number of a device it will recall
that number every time I connect it.  It does have to be done for each
port it is plugged into but I don't have to check or change it every
time I plug it into the same port.

Rick

On Mar 20, 6:52=A0pm, DaveN <Da...@DaveN.com> wrote:
> On 20/03/2011 17:30, rickman wrote:
>
> > 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. =A0There are
> > FTDI devices that directly support a JTAG output which is used in a
> > number of JTAG adapters for various MCUs. =A0Is that the sort of thing
> > you are considering?
>
> > Rick
>
> I was thinking that the original question was about backdoor debugging.
> =A0 To me that means either in the "old" days using an emulator or now
> using the JTAG port. =A0The use of serial over USB, USB direct, ethernet,
> CAN or whatever is just a way of communicating with the system. =A0You ma=
y
> 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.

When you use the FTDI JTAG device, what is your target and what
software are you using?  Is this open source software like OpenOCD or
something you rolled yourself?

I'm trying to get someone to add the Freescale Kinetis support to his
tool so I'm looking to understand all the details of what this
requires.  The Kinetis eval boards come with OSJTAG implemented in an
8 bit Freescale MCU.  Or this is also called OSBDM.  I can't seem to
figure out just how difficult it will be to get adequate info to add
support for this through OpenOCD.  It seems like the OSJTAG source
code would have to be reverse engineered to get the interface spec.

Rick

On 21/03/2011 20:33, Paul wrote:
> In article<im85qk$ejk$1@reader1.panix.com>, invalid@invalid.invalid
> says...
>>
>> On 2011-03-21, Chris H<chris@phaedsys.org>  wrote:
>>
>>>>>>> The problem is you never really know what caused the LED to light.
>>>>>>
>>>>>> While I suppose that's true in a theoretical sense, it's not true in a
>>>>>> practical sense.  In the real world (at least the one I work in), you
>>>>>> do know what cause the LED to light.
>>>>>
>>>>> No you don't you only think you do.
>>>>>
>>>>
>>>> Ok, it's time for me to learn something new because I don't know what you
>>>> are getting at.
>>>>
>>>> Example setup: GPIO pin, with LED + resistor attached, is configured
>>>> for output and is set low by writing a zero to the appropriate bit in
>>>> the appropriate GPIO register at program startup.
>>>>
>>>> The interrupt handler sets the appropriate bit in the GPIO register
>>>> when it's called, causing the LED to light and hence signalling that
>>>> the interrupt handler has been triggered.
>>>>
>>>> Question: Why can't I assume that the interrupt handler has been
>>>> successfully triggered ?
>>>>
>>>> If you are arguing that the code could scribble over the register
>>>> causing the LED to light at random, then I accept it's possible in
>>>> theory, but in practice, I have never seen a bug like that in my code.
>>>
>>> How would you know?
>>
>> Seriously?  You have no way to tell if your software is working other
>> than by looking at a trace from an ICE?
>>
>>> You have no real idea what actually caused the line to toggle nor the
>>> events that lead up to it.
>>
>> Actually, Yes, I do have a pretty good idea.
>>
>>> With a decent ICE you do know and you have the full trace and
>>> timings.
>>
>> Thats true, but it's pretty much a moot point.  None of the parts I've
>> used for the past 15+ years or so have had "decent ICE" availble.  The
>> 68HC11 was the last part I used for which ICE with any tracing
>> capability was available. That was sometime around 1991.  I've used
>> probably a dozen or so parts with JTAG interfaces, but none of them
>> had any tracing or timing analysis capabilities.
>
> ICE came in various forms
>
> Bond Out
> Emulation
> Pin moditoring
>
> These days bond out is too expensive to do for the complexity of
> the of the devices and would require special wafers to make larger
> sized die to hold all the required bond out wires to look before and
> after pipeline and caches. Let alone myriad of busses and multiple
> cores. Anything beyond the simplest 16 bit mcro with EXTERNAL
> memory becomes difficult.
>
> Emulation is even harder to do at hardware level.
>
> Pin monitoring to detect what the processor is doing is pointless as
> many micros above 8 bit have all sorts of pipelining, even a few stages
> of bus bridges and buffering can make it difficult to determine what
> actually is happening to crete a useful trace buffer.
>
> I have seen so few ICE systems (not JTAG/SWD/BDM) for over 10 years).
> They were always expensive as the majority were special bond out or
> emulation types in small volume runs.
>

A number of devices have tracing features in their JTAG/BDM debugging 
system (such as the ARM ETM), to allow a certain amount of tracing. 
Using such arrangements is expensive, and only occasionally useful, and 
often means slowing down the core or disabling caches.  But they are a 
lot cheaper than a full ICE would be.

It would also be perfectly possible to emulate smaller micros in modern 
FPGAs.  You wouldn't even need a particularly large or fast FPGA to do 
cycle-perfect emulation of an AVR, for example.  And I presume that 
Atmel already has VHDL (or possibly Verilog) models of the devices to 
give them a starting point.  The fact that such emulators are not on the 
market is a good indication that they are not considered to be worth the 
money - JTAG/BDM debugging combined with simulation on a PC is sufficient.

On 21/03/2011 19:19, Chris H wrote:
> In message<im8393$de5$1@news.eternal-september.org>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP>  writes
>> On 2011-03-21, Chris H<chris@phaedsys.org>  wrote:
>>> In message<im7oq5$57h$1@reader1.panix.com>, Grant Edwards
>>> <invalid@invalid.invalid>  writes
>>>> On 2011-03-21, Chris H<chris@phaedsys.org>  wrote:
>>>>>
>>>>>> You missed out LED (+ current limiting resistor) connected to a
>>>>>> GPIO pin. :-)
>>>>>
>>>>> true
>>>>>
>>>>>> Great for debugging interrupt routines.
>>>>>
>>>>> But not as good as an ICE or LA
>>>>
>>>> On many platforms, ICE is useless for things like timeing measurement.
>>>> An LED (or better yet a few of them) works brilliantly for timing
>>>> measurements.
>>>
>>> Assuming they are available for the part AFAIK the ONLY thing that is
>>> any good for timing measurements are ICE or LA.
>>>
>>>
>>>>> The problem is you never really know what caused the LED to light.
>>>>
>>>> While I suppose that's true in a theoretical sense, it's not true in a
>>>> practical sense.  In the real world (at least the one I work in), you
>>>> do know what cause the LED to light.
>>>
>>> No you don't you only think you do.
>>>
>>
>> Ok, it's time for me to learn something new because I don't know what you
>> are getting at.
>>
>> Example setup: GPIO pin, with LED + resistor attached, is configured for
>> output and is set low by writing a zero to the appropriate bit in the
>> appropriate GPIO register at program startup.
>>
>> The interrupt handler sets the appropriate bit in the GPIO register when
>> it's called, causing the LED to light and hence signalling that the
>> interrupt handler has been triggered.
>>
>> Question: Why can't I assume that the interrupt handler has been
>> successfully triggered ?
>>
>> If you are arguing that the code could scribble over the register causing
>> the LED to light at random, then I accept it's possible in theory, but
>> in practice, I have never seen a bug like that in my code.
>
> How would you know?
>
> You have no real idea what actually caused the line to toggle nor the
> events that lead up to it.
>

It is always possible to make a mistake in programming, and it is always 
possible that one such mistake is a runaway pointer that ends up writing 
data in the wrong place - such as the GPIO's output register.  But if 
you really "have no real idea what actually caused the line to toggle", 
then you have no business working as a programmer.


> With a decent ICE you do know and you have the full trace and timings.
>
>

On 22/03/2011 00:19, rickman wrote:
> On Mar 20, 6:52 pm, DaveN<Da...@DaveN.com>  wrote:
>> On 20/03/2011 17:30, rickman wrote:
>>
>>> 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.
>
> When you use the FTDI JTAG device, what is your target and what
> software are you using?  Is this open source software like OpenOCD or
> something you rolled yourself?
>
> I'm trying to get someone to add the Freescale Kinetis support to his
> tool so I'm looking to understand all the details of what this
> requires.  The Kinetis eval boards come with OSJTAG implemented in an
> 8 bit Freescale MCU.  Or this is also called OSBDM.  I can't seem to
> figure out just how difficult it will be to get adequate info to add
> support for this through OpenOCD.  It seems like the OSJTAG source
> code would have to be reverse engineered to get the interface spec.
>
> Rick

Hi Rick,

I'm working with Infineon parts and using the Hitex debugger interface. 
  It's a commercial system and also supports ARM devices.  So probably 
not a great deal of hep to you.

I think getting to grips with the JTAG interface isn't a trivial task by 
any means.  I've noticed that a lot of the the tool vendors offer free 
download limited code size versions of the debugger tools, so this may 
be help to you, if indeed there is one for your part.

Dave.

rickman wrote:
>My Vista machine has COM256.  So clearly they can go pretty high.  Is
>this really much different from IP addresses and such?  It's just a
>number right?  The software that is stuck at COM1-COM4 are still
>thinking they need to handle the interrupt and IO port.

The problem is stability, not the range of valid port numbers or what
type of support a program needs.
The annoyance I refered to is having a working system stop working,
because a COM port number changed. (In many cases without any
provocation from my part.)

--
Roberto Waltman

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

On Mar 22, 5:13=A0am, DaveN <Da...@DaveN.com> wrote:
> On 22/03/2011 00:19, rickman wrote:
>
>
>
> > On Mar 20, 6:52 pm, DaveN<Da...@DaveN.com> =A0wrote:
> >> On 20/03/2011 17:30, rickman wrote:
>
> >>> 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. =A0There ar=
e
> >>> FTDI devices that directly support a JTAG output which is used in a
> >>> number of JTAG adapters for various MCUs. =A0Is that the sort of thin=
g
> >>> you are considering?
>
> >>> Rick
>
> >> I was thinking that the original question was about backdoor debugging=
..
> >> =A0 =A0To me that means either in the "old" days using an emulator or =
now
> >> using the JTAG port. =A0The use of serial over USB, USB direct, ethern=
et,
> >> CAN or whatever is just a way of communicating with the system. =A0You=
 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 devi=
ce.
>
> >> Dave.
>
> > When you use the FTDI JTAG device, what is your target and what
> > software are you using? =A0Is this open source software like OpenOCD or
> > something you rolled yourself?
>
> > I'm trying to get someone to add the Freescale Kinetis support to his
> > tool so I'm looking to understand all the details of what this
> > requires. =A0The Kinetis eval boards come with OSJTAG implemented in an
> > 8 bit Freescale MCU. =A0Or this is also called OSBDM. =A0I can't seem t=
o
> > figure out just how difficult it will be to get adequate info to add
> > support for this through OpenOCD. =A0It seems like the OSJTAG source
> > code would have to be reverse engineered to get the interface spec.
>
> > Rick
>
> Hi Rick,
>
> I'm working with Infineon parts and using the Hitex debugger interface.
> =A0 It's a commercial system and also supports ARM devices. =A0So probabl=
y
> not a great deal of hep to you.
>
> I think getting to grips with the JTAG interface isn't a trivial task by
> any means. =A0I've noticed that a lot of the the tool vendors offer free
> download limited code size versions of the debugger tools, so this may
> be help to you, if indeed there is one for your part.
>
> Dave.

Yes, sure, there are free tools available.  I expect to buy an eval
board which will come with a full toolset.  But I am looking for
something a bit different and to get there I need to adapt debugging
tools.  Someone I know has done this for some of the other CM3
processors and I am encouraging him to lead the way on the Kinetis
parts, partly because I think they are going to be a very good line of
devices and partly because by learning how this is done I can learn
how to make the changes I need.  His work is half way there for me, so
it will be about the best starting point I could hope for.

Then there is also the issue that Freescale is representing that their
eval boards offer "Open Source JTAG" and I'm still trying to figure
out if that is really anything worthwhile or if it is just a way for
marketing to make it sound like they are offering hooks into their
debugging process while still keeping it closed for the most part.

Rick

On Mar 22, 9:00=A0am, Roberto Waltman <use...@rwaltman.com> wrote:
> rickman wrote:
> >My Vista machine has COM256. =A0So clearly they can go pretty high. =A0I=
s
> >this really much different from IP addresses and such? =A0It's just a
> >number right? =A0The software that is stuck at COM1-COM4 are still
> >thinking they need to handle the interrupt and IO port.
>
> The problem is stability, not the range of valid port numbers or what
> type of support a program needs.
> The annoyance I refered to is having a working system stop working,
> because a COM port number changed. (In many cases without any
> provocation from my part.)

Do you mean it changed while running or it changed between one bootup
and the next?  I haven't seen the com port number change other than
when I plug the device into a different port.  Are you saying that
without changing the configuration or connectivity the port numbers
can change?

Rick

On 2011-03-21, Chris H <chris@phaedsys.org> wrote:
> In message <im8393$de5$1@news.eternal-september.org>, Simon Clubley
><clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>>
>>If you are arguing that the code could scribble over the register causing
>>the LED to light at random, then I accept it's possible in theory, but
>>in practice, I have never seen a bug like that in my code.
>
> How would you know?
>
> You have no real idea what actually caused the line to toggle nor the
> events that lead up to it.
>

You most certainly do (at least in practice, if not in theory).

Typical debugging session:

Place LED trigger at start of interrupt routine. Light goes on. Good.

Move LED trigger further along the code until either a expected code
path is not taken or until a code path is taken but with invalid data.

Fix code while wondering what you were thinking while writing said code.

End of session (at least for that bug).

For quicker debugging, optionally instrument the interrupt handler with
several LEDs if you have the GPIO lines available.

If your search through the code is causing the LED to light up at random,
then consider other possibilities. In practice, this does not happen for me
and the above process allows me to get close enough to the problem to see
the root cause.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Chris H wrote:

> 
> With a decent ICE you do know and you have the full trace and timings.
> 
>

An ice can be usefull, but is a very expensive, complex solution. It's 
usually cpu specific and requires good host software to get right, 
especially for high internal peripheral count devices. All this costs 
serious development time and money. Other than bdm, it was just about 
the only solution available in the old z80, 68xx days, but modern micros 
have (effectively) made ice obsolete by building in dedicated microcode 
for the debug function. Imho, microcode is the right way to do this, as 
you have unlimited access to the actual hardware running in real time 
and without all the stray capacitive loading and other anomalies that 
are possible using ice hardware.

In the past, many companies had no choice but to develop systems by the 
'code, burn eprom and test' method, such were the cost of ice style 
development tools, but there are so many solutions now that every 
engineer involved in a project can afford to have full debug capability 
on their own machine. I would call that progress, though perhaps the old 
style tool vendors would disagree...

Regards,

Chris

In message <KM3ip.82183$5X6.15317@newsfe20.ams2>, ChrisQ
<meru@devnull.com> writes
>Chris H wrote:
>
>>  With a decent ICE you do know and you have the full trace and
>>timings.
>>
>
>An ice can be usefull, but is a very expensive,

Not expensive in real terms.

>devices. All this costs serious development time and money.

Usually a good ICE speeds up development and bug hunting... also used to
sue then for unit testing.

>Other than bdm, it was just about the only solution available in the
>old z80, 68xx days, but modern micros have (effectively) made ice
>obsolete by building in dedicated microcode for the debug function.

Not really. Jtag is not the same thing.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

rickman wrote:

> 
> When you use the FTDI JTAG device, what is your target and what
> software are you using?  Is this open source software like OpenOCD or
> something you rolled yourself?
> 
> I'm trying to get someone to add the Freescale Kinetis support to his
> tool so I'm looking to understand all the details of what this
> requires.  The Kinetis eval boards come with OSJTAG implemented in an
> 8 bit Freescale MCU.  Or this is also called OSBDM.  I can't seem to
> figure out just how difficult it will be to get adequate info to add
> support for this through OpenOCD.  It seems like the OSJTAG source
> code would have to be reverse engineered to get the interface spec.
> 
> Rick

I have a similar issue with the Keil Ulink2 usb - jtag adapter.
Initially wanted to use this on the network via a network usb hub.
Although the debug adapter can be seen at the host end, the Keil ide
can't see it at all, so i'm guessing that Keil bypass some or all of the
host (WinXp and W2000) usb stack. No suggestion or solution was
forthcoming from either Keil or Silabs.

OpenOcd would be ideal way to go, but reverse engineering the Ulink
command protocol would need at least a usb analyser to get started...

Regards,

Chris

ChrisQ <meru@devnull.com> wrote:
> Initially wanted to use this on the network via a network usb hub.
> Although the debug adapter can be seen at the host end, the Keil ide
> can't see it at all, so i'm guessing that Keil bypass some or all of the
> host (WinXp and W2000) usb stack. No suggestion or solution was
> forthcoming from either Keil or Silabs.

I'm pretty sure it's down to too strict timing requirements in Keil's
software. For the same reason it can be difficult getting debug interfaces
to work in virtual machines. IIRC Keil's interfaces use the host class
drivers and don't need custom drivers installed (eg. you can install the
IDE and start debugging without rebooting the machine inbetween).

-a

Chris H wrote:
> In message <KM3ip.82183$5X6.15317@newsfe20.ams2>, ChrisQ
> <meru@devnull.com> writes
>> Chris H wrote:
>>
>>>  With a decent ICE you do know and you have the full trace and
>>> timings.
>>>
>> An ice can be usefull, but is a very expensive,
> 
> Not expensive in real terms.
> 
>> devices. All this costs serious development time and money.
> 
> Usually a good ICE speeds up development and bug hunting... also used to
> sue then for unit testing.
> 
>> Other than bdm, it was just about the only solution available in the
>> old z80, 68xx days, but modern micros have (effectively) made ice
>> obsolete by building in dedicated microcode for the debug function.
> 
> Not really. Jtag is not the same thing.
> 
> 

The last ice used here (last year) was the Renesas unit for the 32c87
series, but must have been at least 10 years since i've seen or used ice
otherwise. The Renasas device was a set of pcb's plugged together that
needed a special adapter socket on the pcb, so the first few prototype 
boards
were non standard build using the (expensive) special adapters. They
were fragile / top heavy to the point that I had to epoxy the adapters
to the board for adequate mechanical rigidity. Different boards within
the set for different devices within the processor family. It worked,
but at over 1000 ukp each, a bit expensive when all I really needed was
code download, run, single step and occasional variable and structure
examination. The software was  good though, shall we say "feature
rich", with regular and free updates from Renesas.

I think the main drive comes from manufacturers, to get critical
mass, with low cost starter kits the way forward to get a cpu family
into wide acceptance. Target hardware kits are often 100 ukp or
less, including quality, limited size toolchains. Hardware emulators at
1000's don't fit into that picture, especially when lower cost jtag
style solutions get 90% of the job done at a fraction of the cost. Any
remaining hardware issues can be dealt with more effectively using a
scope or logic analyser with a few lines of added code where necessary...

Regards,

Chris