unstable mc9s08dr32 debug with the usb-ml-12 pod

[jah]

reference:
pod is a P&E Multilink usb-ml-12 with rev5.4 software
codewarrior ide version 5.6.1.1506 win-xp

on an existing design i can only sometimes get the jtag emulator to load memory and durn. the nature of the bad is:
-difficult to get code into the processor (mc9s08dr32)
-the crystal is 8mhz difficult to keep it set to this
-sometimes it will run but just setting a break point causes an error

all this on an existing project that functions well in the field.

[jah]

i am using a 8mhz resonator and having in circuit debug problems. operation sometimes works but hard to establish that condition. peMicro pod. codewarrior. some code builds work better than others.

[Alban]

Hello Jah,

Are you certain it is an MC9S08DR32 ???
This part number does not exist...

Alban.

[jah]

the haredware peep got 2 letters reversed,
the part is......... MC9S08rd32

[Alban]

OK, I like this one better

It looks like a remote control application. I will say that maybe the oscillator quality is not fantastic on either its Design values or layout on the PCB.

Stand alone, depending on how you use the Stop Modes to save power, the application may seem to work fine. However, on the becnh when you try to program, Resets or clock trouble will show straight away.

Also, it is possible that the part is secured. The application will run perfectly, but you would need to unsecure it to get a proper dialogue.

Another one, is the XTAL at 8MHz a fundamental frequency or overtone ? if the latter, it would explain why it doesn't stay at 8MHz.

If you are using a scope probe on the oscillator circuitry to check the frequency, do make sure you are using a low capacitance probe (<1pF). If you use standard probes (10pF), its capacitance will interfere with the oscillator values and change everything.

The S08Rx family is quite robust. I have worked with it and the only trouble I had was with a oscillator misplaced: too far from the MCU and with power tracks running along the LED powering tracks.

Kind Regards,
Alban.

[RedMountain]

I too have had this sort of problem recently, with a different processor. It does sound a lot like you are having problems with the clock staying steady. You might try playing with the capacitance in the clock circuit - I was able to stabilize a crystal by removing capacitors that I had included in my clock circuit, because the traces themselves provided enough capacitance. With excess capacitance, the crystal has a hard time hitting its resonance, because the feedback isn't strong enough. Needless to say, the next board revision will have much shorter traces.

The processor will use the crystal to generate its clock. This clock may work alright in the field, because everything is relative to the crystal speed, in the eyes of the mcu. In other words, the mcu will execute instructions on clock cycles, whether they are slower or faster (within reason). While this is definitely less than ideal, the chip may work fine for most of the time, because precise timing hasn't been as important. However, when you are trying to interface the chip with another chip (or the debugger module), there needs to be some sort of consistent clock between the two. (Serial communication, for instance, has a common clock, generated by the master and read by the slave) The debugger module uses a SYNC command to match the bus clock on the mcu. Thus, when the clock speed changes, the debugger either tries to resync with the clock, or generates an illegal breakpoint error.

All of that to say I concur with Alban's assertion that it is probably your crystal that is causing you all this grief. The processor may work alright when you're not trying to debug, but the unstable clock is almost sure to crop up later in very annoying-to-fix timing issues if you don't improve its stability.

Good luck!