0
\$\begingroup\$

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.

\$\endgroup\$
3
  • \$\begingroup\$ When toggling the WDT setting, do you also see a change in behaviour on the problem? Or none at all? Can you try to modify the WDT time-out setting and try with it ON and OFF and see any difference then? \$\endgroup\$
    – Asmyldof
    Mar 31 '16 at 22:45
  • \$\begingroup\$ It's been a while since I worked with a PIC but does it have a reset status/reason register? You could check that and see what is causing the reset. \$\endgroup\$ Mar 31 '16 at 22:47
  • \$\begingroup\$ Place a small cap on the ~MCLR pin. Even on chips on which the ~MCLR is disabled, it can still trigger through noise. This has happened to me! \$\endgroup\$ Mar 31 '16 at 22:58
5
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ I think either the XC8-developers, the TL866-developers, or both, should be informed about this issue. Have you filed a bug report? \$\endgroup\$
    – bos
    Feb 8 '17 at 14:20
1
\$\begingroup\$

I didn't find a PIC16F683 as an option... might it be a PIC12F683?

Either way, it sure sounds like a WDT issue.

For the 12F683, setting the watchdog timer off (with the #pragma command) still allows it to be turned on manually using SWDTEN bit (WDTCON<0>). Try clearing that bit in code.

\$\endgroup\$
3
  • \$\begingroup\$ The WDT is usually the answer for me as well. \$\endgroup\$ Mar 31 '16 at 22:57
  • \$\begingroup\$ Very strange, I have set mclr pin off and the pin is still active. Hmmm. It is as though the config bits aren't being set... Maybe something to do with the programmer. \$\endgroup\$
    – Nick Hill
    Mar 31 '16 at 23:04
  • \$\begingroup\$ Yes, getting confused. It is a 12F683. 8 bit. \$\endgroup\$
    – Nick Hill
    Mar 31 '16 at 23:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.