3
\$\begingroup\$

I had to debug a C embedded software in a noisy environment. As a result the integrity test of the JTAG connection had a failing rate between 30% and 60%.

What are the risks to make JTAG accesses in such conditions? I mean:

  • Could I burn the microcontroller?
  • Is it possible to corrupt the non volatile memory forever?
  • Do HW protection mechanism that protect the chip exists? (thus preventing any JTAG accesses [program update, debug session, etc.])
  • Is it possible that the data displayed by the debugger is wrong?

The target is a TI C2000. But I would prefer general answer if possible.

\$\endgroup\$
  • 2
    \$\begingroup\$ If your debug tools are iffy then you're f***ed, in my experience the main risk in your situation is that you'll never be able to figure out wtf is going on and you'll still be debugging in 50 years \$\endgroup\$ – Will Mar 11 '16 at 13:30
  • \$\begingroup\$ @Will: So you mean that my question #4 is at least what is going to happen? \$\endgroup\$ – Plouff Mar 11 '16 at 13:41
  • 1
    \$\begingroup\$ In some cases, especially with flash based MCUs it is possible to lock yourself out of the chip to the point where re-connection is harder. For example, an STM32 part will occasional get a bad load that disables the SWD (mini JTAG) interface and requires manipulation of the reset line during connection, something not usually needed on that series. A lot of this will depend on implementation details of a particular chip. It is also definitely possible to have a surrounding circuit where some states are damaging, for example H bridges that can end up with both high and low side drivers on. \$\endgroup\$ – Chris Stratton Mar 11 '16 at 14:14
  • 1
    \$\begingroup\$ Whether the data in the debugger is wrong depends a bit on stuff like whether checksums are used in your setup and I've no idea of the details of what your tools do. But I do know you need a clear idea of what's going on and something somewhere in the system you can trust otherwise it's extremely hard to establish anything beyond doubt and you'll just go around in circles. debugging is all about figuring out what is going wrong -fixing is usually they easy bit \$\endgroup\$ – Will Mar 11 '16 at 14:29
  • 1
    \$\begingroup\$ Series resistors (50-100ohms) can do magic for jtag/spi/icsp type lines, always worth a try \$\endgroup\$ – Will Mar 11 '16 at 14:31
4
\$\begingroup\$

It is unlikely that you will damage the part, but you may not be able to successfully or usefully use the connection to debug the device. You will never be certain that you are seeing a software error or a failure of your debugger, since some failure modes can result in failure of the debug interface in any case.

Signal integrity issues can often be resolved by reducing the JTAG clock rate. This will effect the performance of software loading and large memory dumps or data watches, but for simple breakpoint and stepping debug will remain usable even at relatively low frequencies. If you are already seeing 60% error, you will be no worse of reducing from 10MHz to 4MHz for example, and it may drop to zero. I suggest trying 1MHz as a starting point. If the performance is unsatisfactory you could try increasing it incrementally to determine the maximum error free rate, similarly if you still get errors reduce it further.

In general the JTAG cable should be as short as possible (<20cm as a guide) - preferably the probe manufacturers original cable without adaptors or extensions.

When this question was posted on SO, you added a comment that the probe was a Blackhawk USB200 - the product has an optional isolation adapter for harsh environments to prevent ground-loop issues. That may solve your problem entirely.

Finally, are you certain that the error rate is due to noise? A common enough mistake is to access the pins used for JTAG as GPIO in the software for example.

\$\endgroup\$
  • \$\begingroup\$ Thanks a lot for this practical advice. I won't be to tried it soon, but I definitely will when possible. Regarding your last question: the JTAG is absolutely perfect out of the full system or in the system using an external power supply for the MCU board. So I don't believe in the software using the GPIOs! \$\endgroup\$ – Plouff Mar 11 '16 at 13:54
  • \$\begingroup\$ if using an external power supply for the MCU board makes a difference perhaps your problem is with the ground connection. If your JTAG ground wire is broken then you might see no issues in one setup (ground goes via usb to laptop or something) and barely at all in another (unconnected grounds floating all over the place) \$\endgroup\$ – Will Mar 11 '16 at 14:35
  • \$\begingroup\$ @Plouff : In light of your comment about working with an external PSU, Will's suggestion about grounding applies. I have updated my answer addressing that possibility. You should update your question with the information about the probe that you gave on SO - edit the question rather than adding as a comment though. \$\endgroup\$ – Clifford Mar 11 '16 at 14:56
4
\$\begingroup\$

Adding my 2 cents. Unable to comment!

We faced a similar issue with the same target(C2000). Very often the device would get disconnected and we had to restart the IDE and flash the code again to debug. We contacted TI and we got the following suggestion.

1) Use an digital isolator such as this between the debugger and the target.

2) Reduce the JTAG cable length. Typically ours is less than 5cm.

It worked just fine.

Edit: Clifford pointed out these things already. Just adding my experience.

\$\endgroup\$
  • \$\begingroup\$ Your 2 cents are worth much more! I'll talk about the digital isolator to my colleges. I hope they'll accept this solution for future designs! Many thanks to you! \$\endgroup\$ – Plouff Mar 12 '16 at 17:55
4
\$\begingroup\$

It can absolutely damage hardware.

Say your IR shift gets corrupted to a MCU or FPGA and you accidentally load EXTEST or enter an IEEE 1532 ISC instruction, and you have not set safe values in the BSR cells. Every BSR pin on that device will immediately assert whatever state happens to be in those cells.

If you have some devices running power electronics for example, and there's no external protection, you could fire both MOSFETs in a switching controller and short voltage right to GND. I've seen this happen multiple times. EXTEST is probably the riskiest instruction that is defined in the specification.

If you can't trust your JTAG setup, I'd stop and fix the problem before proceeding. Even outside of hardware damage, think about all the engineering time you'll waste chasing Heisenbugs that turned out to be a bit flipping every now and then in a DR shift.

Basically, look at your design and consider what happens if every pin on a JTAG device jumps to an unknown state (or all 0s or all 1s) -- chances are you will not be happy with the result.

Other things I've done in the past due to bad JTAG integrity is accidental triggering of security fuses and similar. This would brick the part and require replacing it. By design, JTAG has no integrity checking or error correction -- it's one of the simplest possible busses by design.

\$\endgroup\$
  • \$\begingroup\$ Thanks a lot for this technical details and your feedback according to your experience. That's definitely what I lack: experience. But at least I thought it might be harmful. Thanks I can understand why! \$\endgroup\$ – Plouff Mar 12 '16 at 17:53
3
\$\begingroup\$

While direct physical damage to the hardware device would seem unlikely, if a device includes any sort of write-once configuration fuses there is a very real likelihood that a noisy JTAG connection might cause such a fuse to be erroneously set in a way that would render the chip permanently useless. Further, many processors are used in ways which could cause circuit damage to the CPU or other hardware if the I/O pins were set to erroneous conditions.

Basically I would figure that a noisy JTAG connection could cause the system to erroneously believe that you are giving it whatever combination of commands and data would be the most dangerous. If there's nothing you feed the device that would be particularly damaging, then nothing will be damaged. But if it would be possible to deliberately damage the device using the JTAG, one should assume such damage could also occur accidentally unless one has taken systematic efforts to prevent it.

\$\endgroup\$
  • \$\begingroup\$ Thanks a lot of your feedback. At work some people told me that it shouldn't be a problem. You confirmed my fear: a lot of care must be taken when dealing with JTAG. I'll try to figure out a solution... \$\endgroup\$ – Plouff Mar 12 '16 at 17:51
  • 1
    \$\begingroup\$ @Plouff: There are times when 100% reliability is required; there are others where 99% reliability is more than adequate. Since 99% reliability is often easier to achieve than 100%, being able to recognize when it's good enough can sometimes be quite useful. \$\endgroup\$ – supercat Mar 12 '16 at 17:53
  • \$\begingroup\$ Yes, I definitely agree with your POV. If I can reach 99% of reliability, I'll be more than happy. But I stayed below 70% and around 50% most of the time... So I thought there were something to do about this! \$\endgroup\$ – Plouff Mar 12 '16 at 18:00

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.