Newbie puzzled by HC908 programming

I'm a complete neophyte when it comes to hardware, so I'm sure I'm doing something completely stupid in the way I am trying to program a Freescale HC908QY4CPE.

I built the programming circuit shown in the manual and have tried downloading a program using the protocol documented in the manual. I have checked and rechecked connections, voltages, parts. The oscillator is oscillating, the bits from the serial line are getting to the right input, the 9V is getting to the IRQ line, and so forth. But the device sits there like a lump. I get the backtalk echo from the '125 hooked to the '232; I can see the security bytes and commands arrive at PTA0, I can see the 9.8304MHz on PTA5, the static voltages on the other pins are as per the manual; and I get no response at all from the ROM monitor. It has to be something I'm doing wrong as I've swapped the '908 with another with the same results.

I know I need to sacrifice a goat when I'm configuring a SCSI chain -- and DigiKey doesn't carry them! -- so what am I obviously forgetting here?

Thanks for any advice,

Brian Hetrick

Reply to
Loading thread data ...


The most annoying problem I found with using the Motorola HC908 devices is that after a security failure you MUST turn off power and let the supply voltage drop close to zero (

Reply to

I had similar problems with the QT4 (but interestingly, not the JB8) during my early days with the HC08 series.

Is the QY4 programmed or unprogrammed ? If it's unprogrammed, then the following suggestion is not applicable because it should go into monitor mode anyway:

Try powering up the QY4 after the rest of the circuit is powered up. The MAX232 may not have raised the voltage on the IRQ pin to the required level by the time that the QY4 samples it during startup.

However, regardless of whether it's already programmed or not, you imply that you have created your own program to do the downloading.

This is what I have also done, but to make sure that the programming circuit was working first, I started by using the free download of CodeWarrior for the HC08 to test the circuit.


Simon Clubley,
Microsoft: Bringing you 1980's technology to a 21st century world
Reply to
Simon Clubley

Thank you to both replies.

I now have failures with three implementations of the circuit with two sets of parts, two QT4, and one QY4, and both homebrew loading software and CodeWarrior. One of the QT4s is now a small but energetic hot plate, so I assume I fried it at some point; all the other ICs I've used in breadboarding various diagnostic circuits act like their datasheets say they should, more or less; and all the 908s sit there like turnips, or in one case, a quite hot turnip.

I'm clearly doing something really stupid like counting pins clockwise instead of widdershins, and will seek a local guru who can look at the circuit for two seconds and tell me what's staring me in the face. Or I suppose I could cut my losses and buy a demo board...

Again, thanks.

Brian Hetrick

Reply to

I tracked this down with some dredging through the Freescale user forums. The failed attempts at programming used a USB serial port dongle. When I used an old box with a real serial port, everything worked immediately exactly as intended.

The user forums say USB serial ports are a leading cause of programming failure. Are the things half-duplex, or do they use wildly inaccurate time bases for baud rates, or something?

Reply to

Did you try to use the latest drivers for your USB-serial cable?

The USB to serial dongles are trying to packetize the communication via the USB part. Due to that, there could be a big request - response delay on the serial port. This causes the RS232 handshake problems with some applications. What is funny this problem typically happens with the older embedded development stuff, such as eval boards or ICEs.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

Get mcu h/w that others tout as

easy to start .

I have many ARM 7's .

I will ignore all the software and simply

flatten the pins on several old HC chips

and SRAM chips and build

a state machine to boot the ARM mcu's.

Its actually faster .

My state machine has 3 levels , so

it has max leverage .

First SRAM has the primatives ,

2nd has the address lists , 3rd is

very hi-level .

This way , dont have to create a proceedure

as you would in C/C++ .

With only a few primatives , i can trial-error boot any ARM , if it fails boot , i dont have to alter any primatives , cause they are a ROM Emulator and there is only need to rearrange ( alter the addr lists ,) addresses .

ARM thinks it is branching , but it's in the state machine , because there is where the real addressing sequence is .

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.