We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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?
If simulation & real-life differ, it must be because your simulation has not accounted for something (possibly subtle) that happens in real-life. Are you interfacing to a keyboard/keypad? Have you debounced it?
x is a local variable and uses R7. key_ptr is a global. When timer isr is first entered, x is 0. Why would x start out as zero? You don't show any initialization, so odds are you don't initialize it to anything. In other words, you're looking at the movement pattern of random garbage. Staring at R7 may be even less helpful. If there's no further use of x after line "L3", there's no particular reason for the compiler to keep the value of x stored anywhere --- R7 may very well be re-used for something else. To really understand what's going, you'll have to inspect the compiled code of the entire interrupt handler.
Found the problem to be caused by the compiler option for Code ROM Size for the below particular code. The problematic emulation uses option - "Large: 64K program." causing key_ptr to be incremented by 2 instead of 1 at the MOV. If this is changed to option "Compact: 2K functions, 64K program.", the problem disappear. However, the simulator is able to function properly in both cases.
key_ptr=x; 8F21 MOV key_ptr(0x21),R7
"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!
Found the problem to be caused by the compiler option for Code ROM Size for the below particular code. You'll have to present stronge arguments for that claim before I believe it. As I said: you (and everybody else who's supposed to investigate this for real) have to look at the complete example, with a precisely specified compiler version, options selected, and/or the complete, actually generated machine code for both the broken and the working version of that code.
"Why would x start out as zero? You don't show any initialization, so odds are you don't initialize it to anything. In other words, you're looking at the movement pattern of random garbage." This is a common area where simulation & real-life often differ: Simulators do often initialise their simulated memory to all zeros; if your code relies upon this, it is likely to break when you put it into real hardware where initial memory values are random!