Jtag - a couple of questions

[masterx81]

Hi!
I've seen that exists a standard for debugging the circuits, the jtag, i've also read that can be used to debug a pcb (for example testing the bga package solders).
This would save a lot of time searching the board for problems.
Before buying the jtag interface, i want to know something. The problem is finding the correct testpoints, as not always there is a connector (and also if there is a connector, the pinout can be impossible to find).
So, without using invasive methods (like damaging the pcb for reverse engineer), how is possible to know what are the correct points to use?
Tester, logic analyzer, etc can be useful?
I'm interested mostly for find is a bga package have a bad solder...
In the same way, how it's possible to find, eventually the serial port connections (if present) for debug purposes?
Thanks!

[Syntax Error]

Remember, 'JTAG' is not a standard, it's a concept for testing and debugging. There are as many implementations and uses of JTAG as there are chip and circuit manufacturers. Some designers provide a standard sized pin header JTAG test port on their circuit boards to connect with a 'jtag interface', many others do not. If the jtag pins on a BGA chip are not connected, you are stuck.

Before you begin...


Btw, I've recently been using the open source JTAG suite OpenOCD (  Open On-Chip Debugger ) to break into my router. The documentation is worth a read. http://openocd.org/doc/html/About.html

[tv84]

Tester, logic analyzer, etc can be useful?

http://www.grandideastudio.com/jtagulator/

[MosherIV]

'JTAG' is not a standard, 

Wrong! It is a standard.

https://en.m.wikipedia.org/wiki/JTAG
https://study.com/academy/lesson/joint-test-action-group-jtag-definition-uses-process.html
So, JTAG name may mean a number things, but there is a standard behind it - IEEE 1149.1 standard.

To answer op question, the device(s) under test must support JTAG.
It sounds like boundary scanning is of what the op is interrested in.

There are a number of defacto standards for the connectors and pin out for JTAG connections, I know this because most microcontroller vendors all use the same connectors for there JTAG debuggers.
The JTAG debugger manufacturers all support these connectors.

JTAG boundary scan will only debug the device(s). It will/may not detect bad connections on bga, if there is a bad connection on 1 signal of JTAG port, then the JTAG tool will just tell you that it cannot make a connection to the JTAG device.

You do not find the JTAG serial port, it needs to be there, documented and have a dedicated connector on the board. Sometimes, the connector is un-populated through hole and the manufacturer uses bed of nails pogo pins as the connection.

Hope this helps.

[Syntax Error]

For clarity, jtag is not standardIZED, like USB or Wifi. You cannot buy a jtag reader, plug it into a standard jtag pin header, and straight away read a chip or board, like you can with the serial debug port. For standard read, diverse implementation.

Not all jtag readers work with all hardware architectures, so be sure your jtag reader is compatible before spending your money. And that's if you can find the TAP pins.

[masterx81]

Ok, all clear. So the jtag pins (if present) can be spread as single testpoints, and there is no simple way to know every point what do.
I was in the hope to find a "professional" way to know if a board have a failed solder (mainly for bga packages) instead of reaballing every single element (for example, if there is a communication problem between cpu and ram, both bga, how do you know in what of the 2 packages there is a problem).
A bad supply, a shorted or out of spec capacitor, a burnt ic can be spot/measured in some ways, but a failed solder point is not easy. Also if there is a test point for every pin, not knowing what signal pattern have that pin is useless.
Eventually the manifacteur know all for testing the boards after initial assembly, but this informations aren't disclosed. So, if i've well understood, no way to reverse engineer this connections without dismantling the whole board and follow the traces.

[Syntax Error]

Post a photo of your board to see if anyone on the eevblog is familiar with the hardware.

[masterx81]

Was a general question. Nowdays bga packages are almost everywhere. I had the hope of a standardized way to check the board connections (at least for not-so-easy packages). This would be really useful for who repair.

[joeqsmith]

Ok, all clear. So the jtag pins (if present) can be spread as single testpoints, and there is no simple way to know every point what do.
I was in the hope to find a "professional" way to know if a board have a failed solder (mainly for bga packages) instead of reaballing every single element (for example, if there is a communication problem between cpu and ram, both bga, how do you know in what of the 2 packages there is a problem).
A bad supply, a shorted or out of spec capacitor, a burnt ic can be spot/measured in some ways, but a failed solder point is not easy. Also if there is a test point for every pin, not knowing what signal pattern have that pin is useless.
Eventually the manifacteur know all for testing the boards after initial assembly, but this informations aren't disclosed. So, if i've well understood, no way to reverse engineer this connections without dismantling the whole board and follow the traces.

I've designed my own interface and written software to use JTAG to test boards that I have worked on.   The nice thing I could test the basic interconnect, check various peripherals, then once I knew the hardware was good, I could program it.   Obviously I understand the hardware to be able to use the JTAG interface to test it.    It's not something I would consider with a board I knew nothing about and was not documented.   

Motorola had another interface that was a little higher level called Background Debug Mode (BDM).  This interface was unique to Motorola.

[CDaniel]

Was a general question. Nowdays bga packages are almost everywhere. I had the hope of a standardized way to check the board connections (at least for not-so-easy packages). This would be really useful for who repair.

JTAG is not a magical interface for repairs bad solderjoints or components  , it is made for communication / programming and debugging the firmware . OK , you could draw some conclusions communicating , but is very far from what you want .
Test points are not JTAG , they are made to be connected in a testing jig at the factory  ... every product / board are different , so I think you understand it's impossible what you want .
Unfortunatly for repairs you have to use your skills

[Bassman59]

Was a general question. Nowdays bga packages are almost everywhere. I had the hope of a standardized way to check the board connections (at least for not-so-easy packages). This would be really useful for who repair.

JTAG is not a magical interface for repairs bad solderjoints or components  , it is made for communication / programming and debugging the firmware .

Actually, the ability to use JTAG to program memories and debug firmware was not the original reason for the port. It was originally developed to do boundary scan — basically to replace bed-of-nails testing of a PCBA as the density of those assemblies got so high and the number of points to probe did too.

Boundary scan allows the test engineers to shift in known patterns into a chip and those patterns drive chip outputs. Then input pins can be read using the boundary scan and then the test program can determine if shorts or opens are present in the assembly.

Then it became apparent that this ability to shift in data to a device and shift data out from it, with a defined state machine for operation (as opposed to a non-standard thing like SPI) could be very useful for in-circuit programming. Boundary scan and initial program load could be done with one simple wired connection to the target.

And once you had your program loaded, using that same port for debugging firmware was the obvious next step. A microcontroller could have a built-in debug engine. A JTAG port talked to that debug engine and configured it and got data from it. A logic analyzer could be embedded in an FPGA design with the communications/configuration port being standard JTAG.

[joeqsmith]

Was a general question. Nowdays bga packages are almost everywhere. I had the hope of a standardized way to check the board connections (at least for not-so-easy packages). This would be really useful for who repair.

JTAG is not a magical interface for repairs bad solderjoints or components  , it is made for communication / programming and debugging the firmware .

Actually, the ability to use JTAG to program memories and debug firmware was not the original reason for the port. It was originally developed to do boundary scan — basically to replace bed-of-nails testing of a PCBA as the density of those assemblies got so high and the number of points to probe did too.

Boundary scan allows the test engineers to shift in known patterns into a chip and those patterns drive chip outputs. Then input pins can be read using the boundary scan and then the test program can determine if shorts or opens are present in the assembly.

Then it became apparent that this ability to shift in data to a device and shift data out from it, with a defined state machine for operation (as opposed to a non-standard thing like SPI) could be very useful for in-circuit programming. Boundary scan and initial program load could be done with one simple wired connection to the target.

And once you had your program loaded, using that same port for debugging firmware was the obvious next step. A microcontroller could have a built-in debug engine. A JTAG port talked to that debug engine and configured it and got data from it. A logic analyzer could be embedded in an FPGA design with the communications/configuration port being standard JTAG.

Yes!!

So in my case, to clock something into the memory for example, required programming the entire chain three times (to say wiggle the write pin).  Maybe 300 bits to toggle 1 bit.   It was very slow and I thought about using an FPGA to run the state machine to try an improve it.   Still, as slow as it was it sure made testing and setting up the boards a breeze.   

[RoGeorge]

1. What is JTAG?
2. How JTAG works
3. Query the JTAG chain
4. Run a boundary-scan

https://www.fpga4fun.com/JTAG.html

[masterx81]

Was a general question. Nowdays bga packages are almost everywhere. I had the hope of a standardized way to check the board connections (at least for not-so-easy packages). This would be really useful for who repair.

JTAG is not a magical interface for repairs bad solderjoints or components  , it is made for communication / programming and debugging the firmware . OK , you could draw some conclusions communicating , but is very far from what you want .
Test points are not JTAG , they are made to be connected in a testing jig at the factory  ... every product / board are different , so I think you understand it's impossible what you want .
Unfortunatly for repairs you have to use your skills

What skill are needed for know if you not have a cpu not running, not have any known serial debug output, and you have to choose if is failed the cpu solder, the ram solder or the flash solder? Maybe all bga?
In this case i start to reball the most "hot" things, but it's not always the case. And sometimes it's simply failed the chip.
Really hard to repair nowdays things...

[tv84]

What skill are needed for know if you not have a cpu not running, not have any known serial debug output, and you have to choose if is failed the cpu solder, the ram solder or the flash solder?

After all that was hinted, I would say "luck".

[masterx81]

What skill are needed for know if you not have a cpu not running, not have any known serial debug output, and you have to choose if is failed the cpu solder, the ram solder or the flash solder?

After all that was hinted, I would say "luck".

Exactly what i've tought 

[Alex Eisenhut]

Was a general question. Nowdays bga packages are almost everywhere. I had the hope of a standardized way to check the board connections (at least for not-so-easy packages). This would be really useful for who repair.

https://youtu.be/ydhjYAJyeVg

[MosherIV]

In one place I worked at, they x-rayed bga devices to make sure they were soldered correctly.

Some things you can check (for known designs):
Check voltage rails are good.
current draw of board is within range of known good (only after what known good is!)
Check clocks are working - usually there will be test points
If fitted, check for correct LED lights.

[nctnico]

Hi!
I've seen that exists a standard for debugging the circuits, the jtag, i've also read that can be used to debug a pcb (for example testing the bga package solders).
This would save a lot of time searching the board for problems.

Don't be fooled by empty promises. JTAG is nothing more than a physical interface specification for an SPI-like interface. How to do something useful is different for every chip. So you likely need a different interface for every chip unless you are going to write your own software (that is if you can get any meaningful and accurate information). In theory it should be possible to use JTAG to test board connections but this is only useful if all chips on the board support JTAG which is rare. Another problem with JTAG is that it is a clock synchronous interface. If you run it over wires it is highly susceptible to disruptions caused by interference. Personally I try to avoid using JTAG.

[joeqsmith]

In my case, only one part had JTAG.  The rest were just peripherals off this part.  It wasn't that big of a deal to use it to test the hardware but yes the interface was a problem.  I had placed line  drivers/receiver at the end of the cable, very close to the target device.  Maybe 3" or so of cable to the target.  Still, had I rolled it into an FPGA where I sent higher level commands a slower bus, I am sure I could have greatly improved the speed.   

Documentation in my case wasn't a problem.  It was well defined in the databook.  I made up a test board for the logic analyzer to verify it was doing what I expected.  Ah the good old days..