Production Programming HC908

[LDAA_STAB]

My Test Engineer has been pulling his hair over a certain <un-named> programming device. 

This isn't the first time.  Seems whenever a HC908-based product is implemented Test Eng'g faces the same issues implementing on-board programming.  Programming hardware implementation is "by the book" yet reliabilty of the programmer is low and throughput is dismal. 

We run high-volume products and need solid, reliable programming/verification with high yield rates.

Can anyone here share their favorite HC908 programmer types?

Tnx

[Sparks]

Not a design engineer or programmer myself (but with a limited foundation of knowledge), but I was using a custom built in-situ programmer that had all sorts of problems and had halted my production as it reached the point that I couldn't get anything to program effectively.

Managed to get a Cyclone Pro from the UK distributor next day and after a few hours of learning the system I had a whole batch of HC08 boards programmed and tested without a single glitch - and a big thank you to the tech support guy at P&E for walking me through the unit on the phone - so I would wholeheatedly recommend this programmer as an option for consideration.

Jeff F

[JorgeB]

Hi,
A design office here in Buenos Aires had developed and is selling a small, cheap and reliable production programmer for the HC908 devices. It has been in market for five years. Take a look at http://www.qtimicro.com.ar/en/saprog08en.html
This interesting tool take power from the target, has encrypted communications, is password protected, can limit the quantity of mcu can be programmed with each load, can store up to 8 different programs and has a very low cost. You load the s19 and specific programming routines for your device with a simple and intuitive win application.
There is another new model which supports some competitor´s devices and doubles the memory capacity.

May be this info would be interesting for you.

Thanks
regards,

Jorge from Argentina

[ThaManJD]

I have been satisfied using the P&E Micro Cyclone. And if its s08 stuff their BDM has also operated solidly. Had some small issues moving from 2000 to XP but this was resolved with an update version very quickly.

The MON08 interface likes to have some signals at 0V when entering modes. On one or two devices i had to increase the power cycling time to allow onboard capacitors to discharge.

Programmers without controlled power cycling can be frustrating. Figuring when to connect the MON08 connector and apply power then pressing the program button can becom an clumsy art. 

The MON08 interface io pins should be routed only to a MON08 programming header/connector and then jumpered after programming if they need to be used as io ( i try to avoid using them for io if possible).

Also ive heard of people having fatal and intermittent problems with USB to serial converters - if the programmer runs off serial. I havn't found the need to use one but there'd be others in this forum who have tried several and might have recommendations on the best type.

John Dowdell

[ThaManJD]

hehe ignore that. thatll teach me to read the whole thread

[peg]

Hi,

One trap to watch out for, especially when trying to speed things along with automation is the generation of  a correct POR. The voltage on the device must drop to less than 100mV on some devices for this to occur reliably.

[LDAA_STAB]

Hi Peg,

Thanks for the reply.  We are very aware of the Vreset spec.  Got caught on that one very early in dev cycle.

[bigmac]

Hello,

You do not detail the sort of failures that are occurring.  Are you getting a failure to communicate in monitor mode, a failure to program the devices, or are you getting at least partial programming, but with verification errors?  Do you always specifically verify after programming?

For on-board or in-circuit programming (ICP) the reliability could be dependent on exactly how the MON08 interface is implemented within your circuit.  For the pins involved with the programming, is there sufficient isolation from external circuitry, whilst programming?  You could verify that none of the applied signals is "borderline", perhaps due to loading by the external circuitry.

I have been using a MON08 Multilink device for a few years now, and have never observed programming reliability problems - once any problems with the MON08 interface were sorted.

Regards,

Mac

[LDAA_STAB]

BigMac,

Couple of other items in answer to your questions.  The products were specifically designed to allow access to the programming pins on the uC - two of the selection pins normally appear on dip switches which the main test equipment pull to ground during programming.  The other two selection lines are pulled high by onboard pull-up resistors.  We use the local uC clock which is implemented as a crystal and associated components.  The MON08 interface is a 4-pin header containing IRQ*, RESET*, PA0 and ground.  The header pin signals are picked up using "pogo-pins" on the test fixture, signal lines are kept short, twisted with ground to the programmer interface.  External circuitry was purposely isolated from the select and communications lines during programming phase.  During programming power is applied to the entire board with appropriate delays programmed into the programmer to handle power-up and power-down cycles.  All signals, when measured with a scope and appropriate probes show "textbook" signals.

We have been building the main product line for about 5 years.  The older products use an earlier version of the same programmer family and have not given any problems.  The trouble started when we released a variant of the earlier product versions.  The newer products are programmed on the bench using an early version of the programmer and program consistently well.  Attempt to program the new product with the new programmer on the bench and we see the same behaviour as in the production tester.  We have swaped the new programmer with others bought about the same time and the behaviour follows the programmer.  We run diagnostics on the programmers and they report back okay.

As you could imagine, this exercise is beginning to get a bit frustrating.

[peg]

Hi,

If you are simply reporting the facts about your experience with a piece of commercial equipment, then I can see no reason to withhold the details (name) of it.

The manufacturers of these things regularly watch/participate in these forums.

Who knows, exposing their shortcomings here could aid peoples choice of this equipment and also perhaps "grease the wheels" of the support department.

[P_EMark]

I have to say, I wholeheartedly agree with Peg. If, for instance, it were a P&E interface you were having problems with, I would like to hear about it directly (chances are we could get you up and running in no time). If, however, you're stimply having problems implementing the MON08 interface on your own... well, then I'd say that you've become a member of a very, very, large club. :smileyhappy:

P&E's Cyclone Pro is a professional grade production programmer. Some of the notable features include standalone (no PC required) programming, LCD display, and support for multiple images. More details are available on the product page, linked above. The Cyclone Pro is currently used in many high volume production facilities world wide, and has proven itself to be incredibly reliable.

Regards,    
    Mark    
    P&E

[LDAA_STAB]

At present, the most predominate failure is memory image corruption followed by lack of adequate control over the programmer - biggest flaw is positive control over Vpp on the IRQ* line.  Image corruption is being handled by the PC control s/w verifiying the image after every programming cycle.  Initially the IRQ* line is at Vcc.  After programming a single device the programmer leaves IRQ* sitting at VPP.  We have implemented EIA-232, USB and Ethernet interfaces to the programmer using the manufacturer's "special" DLL to attempt to achieve finer control over the programmer to no avail.  We have found the only way to get IRQ* back to Vcc is to reset or power cycle the programmer. We have addressed the reset voltage requirement and guarntee the reset voltage is well below 100mv after removal of Vcc.  We have arranged UUT power switching so the the programmer controls power application to the UUT during the programming stage. 

Side note:  the same programmer has been implemented in another piece of factory test equipment by a different engineering group.  They report similar experiences as ours.  They finally resorted to controllilng the primary power to the programmer to do a complete power-cycle on the programmer when it mis-behaves.

These are some of the reasons I have decided to look around the market to determine if anyone builds a real production quality programmer.