Timer initialization problem

If I remember correctly, Keil Monitor 166 uses an interrupt with priority level 15. Most llikely setting priority level of Timer 0 interrupt to 15 disrupts the Monitor's operation. If it's possible in your application, try reducing priority level of Timer 0 interrupt to a lower value.

Regards,
- mike

If I remember correctly, Keil Monitor 166 uses an interrupt with priority level 15. Most llikely setting priority level of Timer 0 interrupt to 15 disrupts the Monitor's operation. If it's possible in your application, try reducing priority level of Timer 0 interrupt to a lower value.

Regards,
- mike

I don't know what the rest of your code or system looks like but I don't see a problem here. Your code runs fine on a Phytec C167CR starter kit as shown here using the Phytec KC167 monitor via the BSL.

#include <reg167.h>

unsigned int counter;

void initTimer(unsigned int reloadVal)  {
  T0REL = reloadVal;
  T0  = reloadVal;
  T01CON = 0x0042; /* Prescalar = 32, Timer Mode, Timer enabled */
  T0IC = 0x007C;   /* T0IE = 1 ILVL=15 GLVL=0 */
}

void main (void) {
  IEN = 1;
  initTimer(0x20);

  for(;;) { ; /*forever*/	}
}

void T0_IRQ(void) interrupt 0x20 {
  counter++;
}

Here is what I use to initialize the timer 0 on my XC167 board:

  // Setup the timer 0 interrupt
  CC1_T0REL  = 0x0000;	  // Count from this value to FFFF
  CC1_T0     = CC1_T0REL; // Holds current count
  CC1_T0IC   = 0x44;      // set T0IE and ILVL = 1
  CC1_T01CON = 0x40;      // Start interrupt timer 0
  PSW_IEN    = 1;         // set global interrupt enable flag

//**************** Timer 0 Interrupt ********************************//
void timer0(void) interrupt 0x20 using INTREGS {// Timer 0 Interrupt
  static long unsigned tc = 0;
   // Some Code Here
}

One thing that has made my programs work on the simulator and not the real device is over-writing variables by doing something like writing more characters to a buffer than it can hold. The simulator does not always catch this.

I rather strongly doubt the correctness of that analysis. The simulator and real hardware are equally unlikely to catch simple buffer overflows. Hardware doesn't ever catch plain buffer overflows. The simulator may, but only if they overflow not just the buffer, but the entire configured memory space. What hardware does in such a case depends on the hardware. If it trips on something the simulator didn't detect, that's a sign of mis-configuration of the simulator, e.g. by claiming you have more memory than you actually do.

If a program works better in the simulator than on the metal, that's almost certainly for other reasons. Most prominently these two:

1) real memory comes up with random content after power-up, the simulator tends to boot with all RAM filled with zeroes. If this makes a difference to your program, that's a bug in the code (uninitialized variables).

2) crashing or misbehaving peripherals that aren't simulated at all.

"2) crashing or misbehaving peripherals that aren't simulated at all."

Or even real peripherals that are behaving perfectly correctly, but the simulation was flawed...