HCS08 Prototype Appears to Hang Without Debugger

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

HCS08 Prototype Appears to Hang Without Debugger

1,409 Views
ewhac
Contributor I
I'm developing on an MC9S08RG60 (HCS08 variant) using the CodeWarrior tools. My development cycle has been to have the prototype connected to a BDM debugger, which loads the software, resets the CPU and then stops it at main(). I press F5 and test. Last week, someone else tried using the prototype without the benefit of the debugger, and nothing worked. The behavior is quite odd, and after some testing and extensive searching here, I'm no wiser. Here's what I've learned so far.

If the prototype is powered up with nothing attached, nothing works.

If the prototype is powered up with the BDM already attached, but no debugger running, nothing works.

If the prototype is powered up, and then the BDM is attached (no debugger), then it seems to work correctly.

If the prototype is powered up with the BDM already attached, and then the debugger is launched using "Hotsync", then it will sometimes work. (If I then have the debugger stop the prototype, the debugger shows the prototype in a sane place, suggesting it is/was executing code correctly.)

Can anyone offer insights as to what we might have done wrong?

Schwab

Labels (1)
0 Kudos
3 Replies

388 Views
peg
Senior Contributor IV
Hi Schwab,
 
Sometimes this can be that you only single step in the debugger and don't run for long enough to trip the COP. Or that you are displaying variables in the debugger (and so reading them) that you are not doing properly in your code (e.g. status registers neccesary to clear interrupt flags)
 
Just a couple of thoughts
Regards
David
 
0 Kudos

388 Views
ewhac
Contributor I

peg wrote:
Sometimes this can be that you only single step in the debugger and don't run for long enough to trip the COP.

I don't believe so. I've done hours-long continuous runs within the debugger, and the COP is reset in several places.


Or that you are displaying variables in the debugger (and so reading them) that you are not doing properly in your code (e.g. status registers neccesary to clear interrupt flags)

That is an interesting thought. Will closing the memory and data windows be sufficient to test this hypothesis? (That may not explain the starts-working-after-attaching-BDM-pod observation, however.)

Schwab

0 Kudos

388 Views
peg
Senior Contributor IV
Yes just closing windows that display data should be sufficient.
 
Peg
 
0 Kudos