This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Simulator & EPM900 behaviour differs

Hi,

I am using uVision2 with EPM900 for a LPC930 device in Win2K enivronment. However, I have downloaded the lpc900_072004.exe and make use of the LPC9xx examples and start900.A51 file in the uVision2 IDE.

The simulator and emulator is found to be behaving differently for this attached piece of code in the timer isr. At first isr is being called, key_ptr is entered a 2 instead of 1 for emulator enivronment. For simulator, key_ptr is entered as 1 (which is correct).

Details of emulation:
x is a local variable and uses R7.
key_ptr is a global.
When timer isr is first entered, x is 0.
At line L1, x is incremented to 1. At L2, x is still 1 as observed through stepping. At L3, R7 becomes 2 for no apparent reason, and key_ptr is found to be 2 as well!!!

Details of simulation:
Same as above except when L3 is being executed, there is no change in thge R7 and key_ptr is correctly entered as 1!!!

=================
L1: x=x+1;
L2: if(x>=0x05) x=ZERO;
L3: key_ptr=x;
=================

Anyone any ideas?

Parents
  • "However, the simulator is able to function properly in both cases."

    As I said to you before:

    "If simulation & real-life differ, it must be because your simulation has not accounted for something (possibly subtle) that happens in real-life."

    In this case, it's not at all subtle:
    Obviously, the real-life system is constrained by the amount of memory physically available in the hardware.

    "The problematic emulation uses option - 'Large: 64K program.'"

    If you tell the compiler it's got 64K to play with, it will take your word for it, and generate code assuming that 64K is available;
    IF you load this into the simulator, it says, "64K code? sure - I can simulte that!" and it does.
    If you load this code into real hardware that has only, say, 2K of code space - well, you should not be surprised to find that it doesn't work!

Reply
  • "However, the simulator is able to function properly in both cases."

    As I said to you before:

    "If simulation & real-life differ, it must be because your simulation has not accounted for something (possibly subtle) that happens in real-life."

    In this case, it's not at all subtle:
    Obviously, the real-life system is constrained by the amount of memory physically available in the hardware.

    "The problematic emulation uses option - 'Large: 64K program.'"

    If you tell the compiler it's got 64K to play with, it will take your word for it, and generate code assuming that 64K is available;
    IF you load this into the simulator, it says, "64K code? sure - I can simulte that!" and it does.
    If you load this code into real hardware that has only, say, 2K of code space - well, you should not be surprised to find that it doesn't work!

Children
No data