MCU Timing not responding!

Bind your delays to timer hardware. Unless you don't want it to work...
OR write them in assembler

it is the correct action of a good optimizer to say that this code

     for (i = 0; i < 30000; i++)
      { /* Delay for 10000 Counts */
        wait (); /* call wait function */
      }

affect nothing and thus should be ignored

Try setting the optimization level to zero

also what happens when main() ends?

Erik

Bind your delays to timer hardware. Unless you don't want it to work...
OR write them in assembler

it is the correct action of a good optimizer to say that this code

     for (i = 0; i < 30000; i++)
      { /* Delay for 10000 Counts */
        wait (); /* call wait function */
      }

affect nothing and thus should be ignored

Try setting the optimization level to zero

also what happens when main() ends?

Erik

you state above:
// char code reserve [3] _at_ 0x23; // when using on-chip UART for communication
// char code reserve [3] _at_ 0x3; // when using off-chip UART for communication
Indicating you are using a monitor (it took a while for you to tell us that)

and have this

for (j=0x01; j< 0x80; j<<=1)
    { /* Blink LED 0, 1, 2, 3, 4, 5, 6 */
      P3 = j; /* Output to LED Port */

since the UART uses P3.0 and P3.1 something stinks

Erik

All right Thank you very much everybody. And a bigger thanks to some 'WISE' people who found time to criticize people telling them 'idiot' and whatever. It shows your level hahah!! Take care and don't mess anyone else's thread this way. You never know who is there on the other side. So do not display your foolishness on-line at least.

also what happens when main() ends?

The code is pretty awful and his posting techniques severely lacking, but falling off 'main' (surprisingly) isn't an issue here. He's got the:

  while (1)

The code is pretty awful and his posting techniques severely lacking,
which kind of hides that

falling off 'main' (surprisingly) isn't an issue here