I have written the LED flashing light program for a 16F683 microcontroller.
I expected the LED to have a 50:50 mark space ratio. i.e. on exactly half the time. In fact, it is spending longer on than off.
I connected the output to the storage scope and can see that there is a glitch exactly 2.4 seconds after the first switch on. It appears the output is going low, then before getting quite to 0v, is going tristate before going back to +Vcc.
I have checked the #pragma config WDT=OFF which all looks correct. I have tried re – compiling with WDT set to on and off and can see a bit difference in the compiled HEX file.
I am using a MiniPro TL866 programmer.
Best Answer
Thanks all. It was indeed a WDT issue, and the WDT disable bits weren't being set. None of the config register bits were being set.
The programmer has a separate tick box for Con.FUSE Bit . When I program with this set, it gives a programming error, so I thought it was trying to program an un-implemented function on one bit, which I didn't think would affect the WDT etc.
When I program with the tick box ticked, the programmer says error, but the reset glitch has disappeared and MCLR pin is disabled as it should be.
I will investigate why the programmer is giving an error. So anyone with the Minipro, make sure con.FUSE bit is ticked, and ignore the error it throws, as it does actually program correctly.
Update: The PIC XC8 compiler/assembler is setting the two most significant bits in the HEX file for the config register as binary 1.
The Minipro reads back all data including the config register as a verification. When it does so, it reads binary zero from the 2 MSBs. The verification error is thrown by Minipro v6.50 with TL866 programmer.
I have tried flipping all bits in the pragma config fields, it appears all configuration bits are correctly programmed. To fix the error, program a PIC ignoring the error. Read the device, then write out to a HEX file. The new HEX file won't throw an error.
Perhaps the config register is 14 bits long and the two MSBs in the 16 bit word in the HEX file are un-implemented.
If this is the case, and the chip does read back the un-implemented bits as Zero, then it would perhaps be better if XC8 set the bits to the same value as would be read back from the chip. No doubt the PIC programmer has a built-in work-around.