Tell me about it. I still have to support test jigs that I designed over 20 years ago. Back then the jigs were scratched out in a notebook, so the first thing is finding the notebook. An then you have to decipher the hieroglyphics. And if there was software involved, trying to remeber what you did and how it expalins the effect that you are seeing.
We now try to document each jig as if it were a product on its own. The only problem is you only get to make one or two and so the natural debugging that comes from repeated building and testing is missing.
"An then you have to decipher the hieroglyphics. And if there was software involved, trying to remember what you did and how it explains the effect that you are seeing."
And hope the software language still exists and that you have hardware to connect to it. Since you're planning on 20 + years of support, I expect you have those contingencies covered, but I can imagine scenerios where that might not be the case.
For example, the equipment might use old UV-erased EPROMS. If the test equipment was purchsed, rather than developed in house, a bad EPROM or a need for a simple code change might mean the end of that piece of equipment.
I have software laying around my house on 5 1/4 floppy discks, 3 1/2 inch disks, old Mac formatted disks, iOmega Zip drives, and some old EPROMs. Fortunately, I won't be needing any of that, but with a support life like you deal with, you certainly might.
About the PCs running the test software, I suppose that you are using some old version of Windows OS -- maybe Win98/XP. Am I right
Actually some of it goes back to DOS, Windows 95 as well as 98 and XP.
There are 3 OS aspects:
1. Development environment- will you be able tol go back and recreate it to modify the code. Something I really hope to avoid.
2. Operation under a newer OS. Microsoft is normally quite good with backward compatibilty with the glaring exception of point 3, below
3. I/O Drivers- which is far more problematic as Microsoft scaled back first on the parallel port and then the serial port. Some USB to serial port converters work well.
A bigger problem is the changes in hardware architecture and the maintenance thereof- there is the ISA, PCI etc architectures and there is an added complexity in that sometimes you need a system to configure the hardware in situ- so make sure that all you need (software as well) can achieve this on whatever hardware you have left if you ever need to repair/reconfigure.
Also the storage medium can be a problem especially (as Duane noted) if you have everyhthing on 5.25" disks, and you only have 3.5" dirves if you are lucky.
Aubrey: "We now try to document each jig as if it were a product on its own."
I think that's the way to do it. It might only be a one-off, and might not need modifying for a few years, but if you've taken the trouble to document it then you will be able to modify or troubleshoot it easily after a few years. I think it's worth the trouble.
I hear a lot about JTAG, but rearely hear from anyone that uses it a lot for test. The promise is quite good, but it seems a lot more limited in actual use
I share your impression. The devices I see with JTAG interfaces seem to me to be 16 bit logic devices, but I am ignorant of any micro that has aJATG interface that you can control the I/O directly or any interfac device like a DAC/ADC so that comprehensive testing on a small embedded system seems limited.
Having said that I now pause, take a breath and wait for someone to set me right.
I once did a course on FPGAs and one of the exercises was to implement a JTAG interface around the finctions on the FPGA to aid with testing. Seems to be a good idea if you are using this kind of design.
A lot of micros have JTAG capability that can be used for both boundary scan and for talking to the CPU's internal debugging capability. I'm most familiar with ARM Cortex-M, and I've used the capability for ST Cortex-M3 SoCs and Cypress PSoC 5LP. They use the standard debug capabilities from ARM, which are well documented. By talking to the CPU's debug port, you can (by default) read and write any memory location in the SoC, including all memory-mapped I/O. (I say "by default" because someone using the SoC in a product can turn off JTAG debug to prevent reverse-engineering of the product, but leave it on in development prototypes.)
ARM also offers Single-Wire Debug, which allows you to access the debug port over just two wires, a bidirectional data line and a clock. (It's called SWD because there's a version that uses asynchronous coding over just the data line, but I've only seen the synchronous version with separate clock in actual implementations.)
A lot of micros have JTAG capability that can be used for both boundary scan and for talking to the CPU's internal debugging capability. I'm most familiar with ARM Cortex-M, and I've used the capability for ST Cortex-M3 SoCs and Cypress PSoC 5LP.
Thanks for that. I sort of wonder how you do this with the PSoC. I presume you first set up the PSoC into t test specific configuration and then access the all registers to change them? Is that right? It hardly seems Boundary Scan then, but that is purley semantics. Given the complexity, by the time you finsh developing the test (without the aid of PSoC Creator, I presume) it seems that it would be much more complex than a built-in-test.
Freescale (formerly Motorola) calls this "Background Debug Mode". ARM's debug port is the same idea, but uses either JTAG or SWD as the external interface in place of Freescale's proprietary BDM signals.
In any case, the debug module is always there and you can talk to it while a program is running in the CPU. You can do things like stop and start the CPU, and set breakpoints and watchpoints. You can also use the debug module to read and write memory locations, competing with the CPU and DMA for access to the memory buses. You don't need to put the CPU into a test mode -- you can leave the program running.
For testing PSoC devices using JTAG/SWD, you'd probably want to halt the program so it's not writing its own data to the devices. Then you can configure the devices the way you want and exercise them with test data -- all without reprogramming the CPU.
As far as I know, this is not supported by PSoC Creator. I'm old-fashioned, so I like looking at the bare-metal registers. Most people are probably better off writing test programs that run on the PSoC CPU. The JTAG/SWD capability is more for development debugging than for production testing.
...The JTAG/SWD capability is more for development debugging than for production testing.
Which brings up the point that the test techniques and tools requried for production test are (or can be) significantly different from what is requred for development. After all by the time you get to production you presumabley have a working design and you mostly need to check that it's built right and has the right firmware and calabration values loaded if necessary.