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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
USB as standard debug interface
Started by ●March 18, 2011
Reply by ●March 21, 20112011-03-21
Reply by ●March 21, 20112011-03-21
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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●March 21, 20112011-03-21
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!
Reply by ●March 21, 20112011-03-21
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
Reply by ●March 21, 20112011-03-21
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
Reply by ●March 21, 20112011-03-21
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 :-)
Reply by ●March 21, 20112011-03-21
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. > > JJSMy 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
Reply by ●March 21, 20112011-03-21
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
Reply by ●March 21, 20112011-03-21
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
Reply by ●March 22, 20112011-03-22
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.
