First, you prove that a prescaler is there (which I doubt). You can=20 do that by getting CCS to output a lst file, and you analyze what the=20 compiler is doing before it gets to main(). You check to see if it is=20 doing anything with the clock to add a prescaler. You can also look at=20 the disassembly to sanity check the values passed to the delay()=20 function (it's probably a macro). My guess is that a floating input pin RBx is causing interrupts and the=20 isr is using up most of the processors time. So, you check to see if=20 the compiler put any isr vectors in there. And you prevent portb=20 interrupt on change on floating inputs by enabling portb pullups. If you have debugger capabilities, it is easier to do some of these=20 things by setting breakpoints, examining register contents, and single=20 stepping. Inserting dummy code in main() before the loop will let you=20 set a breakpoint. The dummy code should do something that doesn't get=20 optimized out, like "unsigned char n; n =3D PORTB;" If it's the watchdog timer, or something else causing a reset, you will=20 find that if you set a breakpoint before the loop, the breakpoint will=20 be hit more than once. You can also set a breakpoint at the isr vector=20 to see if it is a robue interrupt. Joe W On 6/18/2011 5:03 AM, geetansh wrote: > how can i remove that prescaler then? > > > > RussellMc wrote: >>> when the delay between on off was set >>> 10ms the leds took 2.3sec >> 2300 mS / 10 mS ~~~=3D 256 >> >> Delay MAY be out by a factor of 256, indicating that there is possibly a >> prescaler in the clock that is not being accounted for. >> >> >> Russell >> --=20 >> http://www.piclist.com PIC/SX FAQ& list archive >> View/change your membership options at >> http://mailman.mit.edu/mailman/listinfo/piclist >> >> --=20 Joe Wronski Stillwater Embedded Engineering www.stillwatereng.net --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .