USB as standard debug interface

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

rickman  wrote:
>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...

--
Roberto Waltman

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

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