I used to work in team that develop product based on ARM v7 MCU but used to be application programmer. Now I deep into electronics with PIC/AVR/ARM boards as hobbyist.

We used Segger J-Link programmer/debugger.

Now I think to buy one myself and frustrated by variety of possible JTAG flashing/debugging devices. There are for ARM, for PIC, AVR, some FPGA boards...

Do really each arch require its own type of ICE even if all these devices connected through JTAG?

According to https://en.wikipedia.org/wiki/Joint_Test_Action_Group JTAG is specs and protocol for electrical connection to IC in order to perform Boundary scan testing.

And somehow JTAG link become used for flashing/debugging...

Why industry make specialized hardware for communicating over JTAG link for flashing/debugging purpose instead of making universal USB-to-JTAG adapter and perform "magic" on general purpose PC?

https://en.wikipedia.org/wiki/In-circuit_emulation article say about emulation. But I used real boards with J-Link and debugger shows actual hardware registers (GPIO memory mapped values). Where does emulation make place?

Is that right that I need to update firmware of ICE tool to work with new type of core?

  • \$\begingroup\$ PICs and AVRs don't use JTAG for programming and debugging. In most cases, neither do ARM Cortex devices. \$\endgroup\$ – Leon Heller Sep 29 '15 at 22:19
  • \$\begingroup\$ @LeonHeller I do search on ebay.com by jtag keyword before posting question. Definitely there are JTAG ICE products for AVR/ARM. How common JTAG interface used for such platforms I don't know but that how I made assumption. \$\endgroup\$ – gavenkoa Sep 30 '15 at 6:31
  • \$\begingroup\$ SWD is usually used with Cortex. It uses fewer connections and can be made much smaller than JTAG. Many 8-bit AVRs do not use JTAG. \$\endgroup\$ – Leon Heller Sep 30 '15 at 8:35

It is difficult to write a common denominator implementation, because different architectures have entirely different debugging capabilities, and typically the IDE knows these in order to offer them to the user.

For example, most ARM CPUs have two hardware breakpoints that define a value and a comparison mask for both address and data, and whether the data transfer is an instruction fetch or not. The typical use is to use one for the software breakpoint by trapping on instruction fetch of the instruction word designated as the trap instruction, and use the other one for a single data watchpoint, but that is not always the right configuration -- for example, a "run to cursor" in ROM code might need an entirely different configuration.

At this point, the UI might need to communicate to the user that watchpoints are unavailable in combination with "run to cursor", and a generic JTAG stack and UI would need to find a mode of communication there.

Microsoft's eXdi2 is an attempt at finding such a protocol, but it is fairly high-level, and cannot handle the smaller and more quirky architectures, because in order to at least have some kind of specification, they had to make a number of assumptions about the target architecture.

  • \$\begingroup\$ Thanks for answer! It is difficult to write a common denominator implementation I look for Open Source implementation of software bridge between JTAG dongle and debugger UI/IDE and there is one public accessible in OpenOCD project. There is developer/architecture guide at openocd.org/documentation so anyone may learn how debugging capabilities were implemented. \$\endgroup\$ – gavenkoa Sep 30 '15 at 6:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.