原创 Do we now need a better-than-JTAG solution?

Is a solution better than JTAG now necessary? Hard real-time control software is increasingly common in terms of the number of different items in everyday life that use it. Many items that offer better safety, with equivalent or better energy efficiency, are now possible. But most of the people I know who have recently purchased a new piece of electronics, or a vehicle, or some other device have found at least one bug!

It is becoming increasingly clear that, without help, JTAG-based ICE (in-circuit emulation) is not up to par on many of today's CPUs. Furthermore, JTAG testing and debugging does not allow one to test all the "at speed problems" one encounters in research and development or in production. This is forcing JTAG test escapes to be found by other means. The CAN bus (for controller area network) came out around the same time as JTAG, and both took time to gain momentum. This was when embedded Flash memory sizes were only a few hundred kilobytes in size.

By comparison, modern automobiles and control systems use real-time stacks on 100mbp/sec Ethernet, and 1GHz (or higher) processors with many gigabytes of Flash memory, but they often still use only JTAG for debugging, Flash Loading (often only the boot loader), and partial production test. It is left for each chip maker and OS/OEM to come up with a full Flash load/debug solution on its own. Be it an MCU, an FPGA, or some other device, many are limited in one way or another by limitations in JTAG technology. Isn't it time we come up with a readily affordable, industry-wide solution?

The thing is that bad debug and test capability can have a very real human cost. Allow me to relate a story that will illustrate my point...

Back in the 90s I worked for an aerospace company designing police, fire, medevac, and special mission radios for helicopters and aircraft. We had one Intel ICE for the 8051. The ICE used the old "Bond Out" chip ICE technology. I was not there when the original code was developed and they first attempted to use this ICE. It was bad enough that we were out in a lab in the middle of the desert with a bad ICE.

When we were not dealing with scorpions, poisonous centipedes, black widows, or the occasional side-winder that would craw into our lab (or up through the shower drain in the middle of getting ready for work) we had to find other, less venomous, but equally vexing, "bugs" by the time- honoured tradition of "Burn and Learn." What this meant was that we would "burn" a UV erasable version of the processor and then "learn" whether or not it would then burn out the transmitter.

Dealing with ever-so-great equipment and angry customers that could fly in at any minute to lodge a complaint was never dull. It was also interesting having to handle walking, crawling poisonous bugs while we were frantically wrestling our own black widow's nest of a C compiler riddled with bugs coupled with a bad ICE. The ICE was so complicated to set up and get working—and the power in the lab went out so often—that it was damn near impossible to get it all running right before we lost power along with the working configuration. It was a race against time reminiscent of a "Dr. Who" episode.

This was in the days of DOS, and there was no such thing as an uninterruptable power supply (UPS) for a PC and ICE, let alone a Flash memory in which to save the ICE configuration. This system had actually been designed to use a VT-100 terminal as the interface! Sadly, it had been made for a large corporation that could have easily afforded a plant-wide UPS. Furthermore, the company executives had all been fined for billing all kinds of executive perks to the government, so there was no money for a better ICE when one finally came out.

William Murray
Electrical Engineer