USB as standard debug interface

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     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H
Loading thread data ...

In message , Jon Kirwan 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...... :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

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

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

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
 Click to see the full signature
Reply to
Grant Edwards

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
    PC Services
 Click to see the full signature
Reply to
Paul

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
    PC Services
 Click to see the full signature
Reply to
Paul

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 to
DaveN

,

to

o

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

Reply to
rickman

has

to.

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 to
rickman

y

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 to
rickman

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.

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

Reply to
David Brown

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.

Reply to
DaveN

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 ]
Reply to
Roberto Waltman

e
g
.

now

et,

may

ce.

o
y

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

Reply to
rickman

s

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

Reply to
rickman

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
Reply to
Simon Clubley

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

Reply to
ChrisQ

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 ]
Reply to
Roberto Waltman

Not expensive in real terms.

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

Not really. Jtag is not the same thing.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

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

Reply to
ChrisQ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.