Hiwave.exe - difference between full chip simulation and debugging - hcs908aw32

[benki]

Hi,

         Can somebody help me out with this ? what is the difference between full chip simulation and debugging with hardware in hiwave.exe.

I'm using hcs908aw32 controller. whenever program encounter a while loop, program control doesn't come out of the loop.

Added p/n to subject.

Message Edited by NLFSJ on 2008-03-06 11:47 AM

[peg]

Hello and welcome to the forums, benki

I'm not sure of the association between the two parts of your question.

As an initial simplistic answer:

In full chip simulation the code runs on a simulated device on the PC.

In Debugging the code runs in the target device whilst being monitored by the PC.

[benki]

hi peg,

           thanks for the info !!

i'm using HCS908AW32 controller for my application. Cyclone pro is the flash tool along with BDM connector. using this setup, i'm tring to debug my code by entring Background Debug mode.

everything works fine untill it encounters a while loop in the code. the first while loop is in clock initialisation function. here i wait for PLL to stabilize to the specified frequency. There is a LOCK bit in the status register which says about the status of PLL. untill that bit is false, program doesn't come out of the while loop.

problem is LOCK bit in the status register (ICGS1) is not getting cleared. so program execution is not coming out of that loop. This bit is not in my control.

so now i get a doubt that, if its executing from the hardware, LOCK bit should get cleared and execution should come out of the loop. is it just simulated in PC ??

i tried to toggle a portpin inside the while loop, and it was not toggling. so is this a simulation or is this executing from the hardware connected ???

if i remove the BDM connection, there is a message - " cannot communicate to Hardware"

i'm really confused with the situation.

[peg]

Hi benki,

Your either simulating EVERYTHING or nothing, no other choice.
In simulation you will never get stuck waiting for lock because it simulates good hardware.
If it simulates ok but in real hardware debugging it hangs then you probably have a hardware issue here.
Your not getting a COP reset while waiting for lock are you?
I got trapped by this, what worked everytime on a GT16 causes a COP reset waiting for lock on a GT16A everytime even though nothing supposed to be different in this area.
If you are toggling a pin while debugging you should be able to measure the toggle on the real pin. You should also be able to watch the pin in the debugger.

[benki]

hi peg,

         sorry for the late reply. now i have confirmed that it is not a simulation but its working with the hardware connected. i tried to do some tests with the same setup. i tried to get the bus clock out through a pin (PTC2) MCLK pin. when i execute the code for this, i get the bus clock in this pin.

so now i am sure that, it is executing from the hardware. hardware bits like LOCK, SPI transmitter empty bit, etc... are not getting updated at all.

so whereever i have a while loop waiting for these hardware bits, program execution hangs.

i dont know what's wrong.

benki

[JimDon]

Lets see your code...
The simulator works fine.