USB as standard debug interface
acd
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
Oliver Betz
>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:gec0j65r3h4d8la23...@z1.oliverbetz.de>
Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
Rich Webb
wrote:
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
Roberto Waltman
>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 ]
linnix
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.
Grant Edwards
> On Fri, 18 Mar 2011 09:52:10 -0700 (PDT), acd <acd4u...@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..
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
gmail.com THRU CAPT GROGAN'S LUMBAR
REGIONS!
linnix
> 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
Roberto Waltman
>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
>> > 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... ;)
Rich Webb
<inv...@invalid.invalid> wrote:
>On 2011-03-18, Rich Webb <bbe...@mapson.nozirev.ten> wrote:
>> On Fri, 18 Mar 2011 09:52:10 -0700 (PDT), acd <acd4u...@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.
DJ Delorie
acd <acd4u...@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.
Oliver Betz
[...]
>> 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 Betz
>>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.
Rich Webb
wrote:
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
wrote:
>Roberto Waltman wrote:
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.
rickman
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
DaveN
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.
Chris H
<Da...@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 /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Meindert Sprang
news:p647o6502mcuh9961...@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
Meindert Sprang
news:cs77o6d9s11bvdqa0...@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
Allan Herriman
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
Simon Clubley
>
> 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
Roberto Waltman
>"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
>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.
Chris H
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>On 2011-03-21, Chris H <ch...@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.
Mel
> On 2011-03-21, Chris H <ch...@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.
Chris H
writes
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.
Grant Edwards
>
>>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!!
Rich Webb
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?
David Brown
> In message<im7nnd$r8a$1...@speranza.aioe.org>, Mel<mwi...@the-wire.com>
> writes
>> Simon Clubley wrote:
>>
>>> On 2011-03-21, Chris H<ch...@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...
David Brown
> On 2011-03-21, Chris H<ch...@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.
Roberto Waltman
>...
>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.
Chris H
<inv...@invalid.invalid> writes
>On 2011-03-21, Chris H <ch...@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 H
<da...@westcontrol.removethisbit.com> writes
Happy days.......
John Speth
>>> > direction from which the wind is blowing. Today is COM739, tomorrow,
>>> > who knows...
>>
>
> 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
Jon Kirwan
<da...@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
Jon Kirwan
<da...@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
Simon Clubley
> In message <im7oq5$57h$1...@reader1.panix.com>, Grant Edwards
><inv...@invalid.invalid> writes
>>On 2011-03-21, Chris H <ch...@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.
Grant Edwards
>>>> 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 ...
Chris H
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes
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 H
<jo...@infinitefactors.org> writes
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...... :-)
Grant Edwards
>>>>> 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!
Paul
jo...@infinitefactors.org says...
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 | pa...@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
Paul
says...
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.
DaveN
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 :-)
rickman
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
rickman
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
rickman
> 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
David Brown
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.
David Brown
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.
DaveN
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.
Roberto Waltman
>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.)
rickman
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
rickman
> 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.)
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
Simon Clubley
> In message <im8393$de5$1...@news.eternal-september.org>, Simon Clubley
><clubley@remove_me.eisner.decus.org-Earth.UFP> writes
>>
>>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.
ChrisQ
>
> 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
Roberto Waltman
>On Mar 22, 9:00 am, Roberto Waltman wrote:
>> 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?
Not while a system is running.
But, for example, in a laptop with no serial ports:
Plug an RS-232 dongle for the first time - Becomes COM1
Disconnect, connect in a separate USB port, it is still the only
serial port in the system, but becomes COM-NOT-1
OR disconnect, connect a different USB dongle in a different port,
connect back the original USB dongle in the same port, becomes
COM-NOT-1
Or run out of ports, connect an USB hub, connect dongle to hub,
becomes COM-NOT-1
Or, reboot system with additional USB devices plugged in. COM1 becomes
COM-NOT-1
Repeat until reaching COM739...
ChrisQ
>
> 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
Chris H
<me...@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.
Roberto Waltman
[Things about ICEs ...]
I am curious. Regardless how an ICE compares to JTAG, BDM, etc., you
seem to consider it a viable option today.
I have not used a "real" ICE since the 8080/Z80/6800 days.
I don't recall even seeing an ICE for at least the last twelve years
in the places I worked or visited.
(Excluding web pages for old equipment sold at eBay)
Are In Circuit Emulators still part of an embedded developer's
toolkit?
What companies manufacture them, for what processor families?
Anders....@kapsi.spam.stop.fi.invalid
> 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
Grant Edwards
> Chris H wrote:
>
> [Things about ICEs ...]
>
> I am curious. Regardless how an ICE compares to JTAG, BDM, etc., you
> seem to consider it a viable option today.
>
> I have not used a "real" ICE since the 8080/Z80/6800 days.
Me too. The 68HC11 was the last target with which I used "real" ICE.
> I don't recall even seeing an ICE for at least the last twelve years
> in the places I worked or visited.
>
> Are In Circuit Emulators still part of an embedded developer's
> toolkit?
Nope.
> What companies manufacture them,
Don't know.
> for what processor families?
None of the ones I've used in the last decade had "real" ICE
available. Many of them had JTAG, but that's strictly HW breakpoint,
examine memory, and single-step. No tracing.
--
Grant Edwards grant.b.edwards Yow! Hmmm ... a CRIPPLED
at ACCOUNTANT with a FALAFEL
gmail.com sandwich is HIT by a
TROLLEY-CAR ...
ChrisQ
> In message <KM3ip.82183$5X6....@newsfe20.ams2>, ChrisQ
> <me...@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
Anders....@kapsi.spam.stop.fi.invalid
> None of the ones I've used in the last decade had "real" ICE
> available. Many of them had JTAG, but that's strictly HW breakpoint,
> examine memory, and single-step. No tracing.
Many ARM processors contain an embedded trace module. When Keil introduced
their ULINKpro debug interface, one of the features they pushed was
realtime instruction tracing for Cortex-M devices.
-a
Grant Edwards
> Grant Edwards <inv...@invalid.invalid> wrote:
>> None of the ones I've used in the last decade had "real" ICE
>> available. Many of them had JTAG, but that's strictly HW breakpoint,
>> examine memory, and single-step. No tracing.
>
> Many ARM processors contain an embedded trace module.
True, but none of the ones I've used did. Maybe the next one...
> When Keil introduced their ULINKpro debug interface, one of the
> features they pushed was realtime instruction tracing for Cortex-M
> devices.
That would be nice...
--
Grant Edwards grant.b.edwards Yow! Make me look like
at LINDA RONSTADT again!!
gmail.com
David Brown
> On 2011-03-22, Anders....@kapsi.spam.stop.fi.invalid<Anders....@kapsi.spam.stop.fi.invalid> wrote:
>> Grant Edwards<inv...@invalid.invalid> wrote:
>>> None of the ones I've used in the last decade had "real" ICE
>>> available. Many of them had JTAG, but that's strictly HW breakpoint,
>>> examine memory, and single-step. No tracing.
>>
>> Many ARM processors contain an embedded trace module.
>
> True, but none of the ones I've used did. Maybe the next one...
>
>> When Keil introduced their ULINKpro debug interface, one of the
>> features they pushed was realtime instruction tracing for Cortex-M
>> devices.
>
> That would be nice...
>
It /can/ be nice, but in reality you don't often have need for tracing.
I certainly seldom used it in the old days of using "real" ICE's. On
the other hand, when you /do/ have use for tracing, it can save a lot of
time in debugging.
But tracing is an expensive feature, especially if you only have use of
it once a year. If you have a team of 10 Cortex programmers, it could
make sense to have one expensive debugger (such as the ULINKpro, if you
are using Keil tools) shared in the team, and an ordinary jtag debugger
for each programmer for normal use. But if you are working by yourself,
it would be hard to justify the price based solely on the trace feature.
Tracing has also become far less useful since it became standard to
include some hardware data watchpoints, as well as code breakpoints.
Grant Edwards
> On 22/03/11 20:49, Grant Edwards wrote:
>>> Many ARM processors contain an embedded trace module.
>>
>> True, but none of the ones I've used did. Maybe the next one...
>>
>>> When Keil introduced their ULINKpro debug interface, one of the
>>> features they pushed was realtime instruction tracing for Cortex-M
>>> devices.
>>
>> That would be nice...
>
> It /can/ be nice, but in reality you don't often have need for tracing.
To be honest, I probably used tracing more for tracking down hardware
problems (spurious interrupts, that sort of thing) than for tracking
down software bugs.
--
Grant Edwards grant.b.edwards Yow! My life is a patio
at of fun!
gmail.com
Hans-Bernhard Bröker
> I have not used a "real" ICE since the 8080/Z80/6800 days.
[...]
> Are In Circuit Emulators still part of an embedded developer's
> toolkit?
Well, that would tend to depend on how real an ICE has to be for you to
consider it a "real" one...
I'm pretty sure a pretty realistic ICE (you know, as in: somewhat
clunky box with a many-a-pole flat cable coming out of it that ends in a
plug that fits a socket which could otherwise hold an actual CPU) has
been in use in our shop this year. At least I know who last used it.
The whole thing is for a Fujitsu 16FX series processor. And yes, it's
worth having it in the toolkit.
Roberto Waltman
>On Roberto Waltman wrote:
>> Are In Circuit Emulators still part of an embedded developer's
>> toolkit?
>
>...The whole thing is for a Fujitsu 16FX series processor. And yes, it's
>worth having it in the toolkit.
Yes, of course. I didn't mean that there should not be used or that
they are not useful. When any tool saves a project, it saves a
project.
I was asking, (using a poor choice of words, maybe,) if they are
available at all for newer processors.
.
Meindert Sprang
news:hohho6lo87tnskpin...@4ax.com...
> But, for example, in a laptop with no serial ports:
>
> Plug an RS-232 dongle for the first time - Becomes COM1
>
> Disconnect, connect in a separate USB port, it is still the only
> serial port in the system, but becomes COM-NOT-1
That only happens with dirt-cheap RS-232 dongles without serial numbers.
Windows has no way of recognising it has 'seen' this before so the COM port
number will be tied to the USB port. As soon as you spend a little more on a
RS-232 dongle with a serial number, windows will recognise it the next time
regardless of which USB port it is plugged into, and assign the same COM
port number again. The FTDI RS-232 converters are a good example of this.
Meindert
Chris H
<use...@rwaltman.com> writes
>Chris H wrote:
>
>[Things about ICEs ...]
>
>I am curious. Regardless how an ICE compares to JTAG, BDM, etc., you
>seem to consider it a viable option today.
Absolutely. Not all MCU have JTAG or BDM Also not all MCU have ICE
>I have not used a "real" ICE since the 8080/Z80/6800 days.
>I don't recall even seeing an ICE for at least the last twelve years
>in the places I worked or visited.
Well as I know several ICE manufacturers whilst they are not selling as
many due to the growth in ARM and hence JTAG there are still a lot of
people using ICE where they are available.
However new technologies are coming on stream like SWD for Cortex which
are purpose designed debug solutions a generation on from JTAG.
>Are In Circuit Emulators still part of an embedded developer's
>toolkit?
They should be where appropriate.
>What companies manufacture them, for what processor families?
See
www.lauterbach.com
www.isystem.com
www.hitex.com
There are half a dozen others at a similar level
Oliver Betz
[...]
>However new technologies are coming on stream like SWD for Cortex which
>are purpose designed debug solutions a generation on from JTAG.
Not only "new" debug interfaces are "purpose designed", look at the
single wire "BDM" interface by Motorola. I don't remember exactly when
I started using it, but I think it was more than ten years ago (HC12,
"SDI" interface).
>>Are In Circuit Emulators still part of an embedded developer's
>>toolkit?
>
>They should be where appropriate.
>
>>What companies manufacture them, for what processor families?
> See
>www.lauterbach.com
>www.isystem.com
>www.hitex.com
>
>There are half a dozen others at a similar level
Like Nohau... I remember them being ardent ICE advocates. How many
_new_ ICE products did all the manufacturers bring out recently?
Oliver
--
Oliver Betz, Muenchen (oliverbetz.de)
rickman
wrote:
If you are using a hub, does the "quality" of the hub have anything to
do with it? I have a FPGA programming adapter that works ok in any
USB port on my machine, but refuses to work when plugged into a hub.
I only have two hubs around and they are both min price units. In
fact, I plug in the hub and it shows up in device manager as a
"generic hub". If the programming adapter is then plugged into the
hub not only does the adapter not show up, the generic hub goes away
and an "unknown device" appears.
Would this be likely to work correctly if I were to get a "better"
hub? FTDI doesn't make hub chips. How can I identify a high quality
USB hub?
Rick
Chris H
<OB...@despammed.com> writes
>Chris H wrote:
>
>[...]
>
>>However new technologies are coming on stream like SWD for Cortex which
>>are purpose designed debug solutions a generation on from JTAG.
>
>Not only "new" debug interfaces are "purpose designed", look at the
>single wire "BDM" interface by Motorola. I don't remember exactly when
>I started using it, but I think it was more than ten years ago (HC12,
>"SDI" interface).
>
>>>Are In Circuit Emulators still part of an embedded developer's
>>>toolkit?
>>
>>They should be where appropriate.
>>
>>>What companies manufacture them, for what processor families?
>> See
>>www.lauterbach.com
>>www.isystem.com
>>www.hitex.com
>>
>>There are half a dozen others at a similar level
>
>Like Nohau... I remember them being ardent ICE advocates.
Nohau stopped doing ICE a while ago.
>How many
>_new_ ICE products did all the manufacturers bring out recently?
No Idea. Most new parts are JTAG
Meindert Sprang
news:aae13651-52e1-460f...@r4g2000prm.googlegroups.com...
> If you are using a hub, does the "quality" of the hub have anything to
> do with it? I have a FPGA programming adapter that works ok in any
> USB port on my machine, but refuses to work when plugged into a hub.
I think so. I have no experience woth dirt-cheap $1 hubs, but I know that
the I have handles for of my devices using an FT232R perfectly. Always the
same com ports. I even tried connecting four devices to that hub and then
connecting the hub to the PC, so the PC would see four similar new devices
at once. No sweat.
Could it be that modern dirt-cheap hubs don't follow the USB specs and just
act as a semi-intelligent USB four-way switch? Just to cut on silicon cost?
Meindert
larwe
> do with it? I have a FPGA programming adapter that works ok in any
> USB port on my machine, but refuses to work when plugged into a hub.
> I only have two hubs around and they are both min price units. In
> fact, I plug in the hub and it shows up in device manager as a
> "generic hub". If the programming adapter is then plugged into the
> hub not only does the adapter not show up, the generic hub goes away
> and an "unknown device" appears.
Is the hub powered externally? Bus-powered hubs can cause a lot of
trouble and odd behaviors like this (they SHOULDN'T, but they DO).