Uwharrie Test Solutions

LLC

Test and Programming Standard for Microcontroller Embedded Flash on Teradyne TestStations and GR228X

This is not today's industry standard. This is a standard that I hope the industry will some day adopt. The success of my business model depends on it happening, and hopefully, I will save the Electronics Manufacturing Industry a few dollars in the process.

These are the goals of this standard. I have already achieved most of these goals with a few devices in each class of Microcontroller I describe below. Tomorrow's challenge will be to put these ideas to use on every popular device on the market and somehow convince the industry that this is the way to go.

  • All Microcontrollers to have their flash programmed at ICT, by ICT, using the driver sensor subsystem and the DSM, without the need for a programming POD or any other fixture installed electronics.

  • All routines to be generated from a Hybrid Model HTS that will plug-and-play after ATG, with little or no modification required by the end user.

    • The programming of unique data to each individual device such as serial number, MAC address, or calibration data is still out of scope for this goal. This can still be done, but the routine to do it will have to be custom developed for each end user.

  • All classes of Microcontrollers to have their GPIOs pin-tested, with failures diagnosed to the pin-level, similar to Boundary-Scan, regardless of the absence of pin-test capability designed into the part.

  • All HTS' to generate a plug-and-play pin-test regardless of pins tied off, tied together, unused or no access.

  • All hybrid models should some day be available to everyone with an ATG license.

  • All code or firmware changes can be handled with a few simple steps, using utilities similar to FlashTool.

  • Most programming routines could be easily modified, with a few simple edits, to program up to 16 devices concurrently, (with different code if desired) in the same time it takes to program a single part.

To better describe how I will achieve this standard, I divide Microcontrollers with Flash into four classes. The testing and programming method and complexity is somewhat different for each class. 

Devices with JTAG and Boundary-Scan Capability

These are the easiest to pin-test because the code can be generated with BasicScan or other Boundry-Scan development tools. This is just a cookbook procedure that almost anyone can do. There is no need to embed the pin-test into the Hybrid Model.

The complexity of the JTAG programming routine varies from one device family to another. This all depends on how complex the programming interface is, and how well the supplier has it documented.

Microcontrollers that fit this class: ST Microelectronics STM32,  most Atmel AVR ATMEGAXXXX. Texas Instruments TMS320 fits this class as well, but TI refuses to reveal the information in a publicly available document.

Devices with JTAG but no Boundary-Scan

The pin-test becomes a little bit more difficult because the Boundary-Scan is not there. The JTAG is usable as a debug port. In which case the entire address spaces is accessible through JTAG, and this includes the GPIO input registers. The GPIO input registers can be read while the GPIOs are driven H/L. Failures can be diagnosed to the pin-level. This test cannot be generated with BasicScan, it has to be embedded into the HTS.

The complexity of the JTAG programming routine varies from one device family to another. This all depends on how complex the programming interface is, and how well the supplier has it documented.

Microcontrollers that fit this class: Texas Instruments MSP430, NXP LPC2292/2294.

Devices with no JTAG and no Boundary-Scan with a Designated Programming Port

These devices are among the most challenging to pin-test, yet among the most rewarding when you make them work. A firmware pin-test routine has to be developed, usually in the Microcontroller's Assembly Language. The firmware is uploaded to the device, usually into program flash, then executed, usually by releasing the reset line and letting it execute. The Microcontroller runs the firmware and the ICT will service the pin-test. It behaves remotely like Boundary-Scan and failures are diagnosable to the pin-level.

These are usually not too difficult to program. This is because the programming port was designed for just that, programming. The only pitfall, with the PIC Micro for example, is the number of different programming algorithms. Each group of PIC 10/12/16/18 has multiple programming procedures, each slightly different from the other, that will handle group of parts within the group. The PIC18 group has 12 different programming procedures to handle a total of 169 different devices.

Microcontrollers that fit this class: Microchip PIC10, PIC12, PIC16 and PIC18. Some PIC24s fit this class, but most PIC24s have Boundary-Scan which simplifies the pin-test.

Devices with UART Bootstrap Loaders

These devices are among the most challenging to pin-test, yet among the most rewarding when you make them work. A firmware pin-test routine has to be developed, usually in the Microcontroller's Assembly Language. This is complicated even further because the pin-test firmware has to be uploaded through the UART. The firmware is uploaded to the device, usually into internal SRAM, then it executes automatically at the end of the upload. The Microcontroller runs the firmware and the ICT will service the pin-test. It behaves remotely similar to Boundary-Scan and failures are diagnosable to the pin-level.

For programming, these are the most challenging I have encountered so far. Your only resource is the UART at first. Its build-in boot-loader will only upload a 32 byte program. This program must be another program that will upload more code through the UART. That program can be a flash programming routine that communicates through a faster channel, like GPIO. Nevertheless the end result is very rewarding, and a big advantage over the programming POD. The use of the GPIO channel can be parallel and quite fast. On the ST10F276 I was able to upload and program 768K of flash in 5.7 seconds.

Microcontrollers that fit this class: ST Microelectronics ST10FXXX, Infineon XC2XXX

Devices with Background Debug Controllers (BDC)

Once you have mastered the communication protocol of the BDC, pin-testing these parts is not too difficult. It's just a matter of reading port data registers while driving the corresponding GPIO. Failures can be diagnosed to the pin-level the same as Boundary Scan.

When you program flash through the BDC, you are at the mercy of the bit rate of the BDC. This usually runs about 500K bits per second.

For HCS08 controllers, the BDC clock and CPU clock is generated by an internal R/C oscillator that can vary in speed. To make the communications more reliable I will do a SYNC command to measure the actual BDC clock speed. Then, I adjust the clock speed of the tester to accommodate these variations. On the HCS08 I can speed up the flash programming by selectively programming only the non-blank locations. You can also reprogram a clock pre-scalier, this magically makes the BDC run at twice the speed. These parts have flash sizes of 4K or 8K, so flash programming speed should not become a bottleneck.

On HCS12 the best way to accelerate the flash programming is to load a routine into RAM and use RAM space as a buffer. The flash programming routine can be developed with the Code Warier development studio. I did mine in Assembly Language. Then a block of code to program to flash can be downloaded into the RAM buffer, and the programming routine is executed. 256K of flash can be programmed in about 15 seconds. HCS12 devices can have up to 1000K bytes of flash. If demand called for it, I could make a routine that pushes the data in parallel through a GPIO. This would run much faster.

Microcontrollers that fit this class are Freescale HCS08 and HCS12.

 

 

 

 

 

 

 

Return to Main Page

Request an HTS That Will Program Microcontroller Embedded Flash

  TSN_logo.JPG (12298 bytes)

 

    ** DEVICE ID TIME      = 0.094 SECONDS
    ** PIN_TEST TIME       = 0.250 SECONDS
    ** PROGRAM/VERITY TIME = 8.984 SECONDS
    ** TOTAL TIME          = 9.328 SECONDS

Test Analysis for U1 (PIC18F6722)
Burst duration 61.067537M sec.
Pin Type Node Special Drives Senses Stuck Ats
-----------------------------------------------
*43 B RB5 DL NDH NSL NSH SLF

Test Summary for U1 (PIC18F6722)
Type Tested Faults Detected Coverage
-----------------------------------------------
Inputs:    4   8   8  100.00%
Bi-dirs:  50  98  98  100.00%
Other:    10  (VCC: 5 GND: 5 UNUSED: 0)
-----------------------------------------------
Totals:   64 106  106 100.00%
===============================================