Figure 4. In this test jig, the control program (written in BASIC) interfaces to industry-standard ModBus modules. Even with the wide variety of options that are available with this approach, every so often you still have to make something custom.
...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.
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.
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.
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.