Post by thread:[PIC] 18F6722 resetting itself

Thanks to listmembers for all the comments on this issue in the past week. I thought I'd let you know how the issue appears to be resolved. First off, it appears that somewhere in my C initialization, or for some other reason, the watchdog reset status bit in RCON was being set prior to the point I was printing it out, so the resets did not appear to be due to the WDT. Using the ICD-2 watch window and setting a break point at the start of my code, then forcing a WDT timeout with while(1), I could see that the RCON bit was properly cleared indicating a WDT timeout at the start of my code, but magically set (hiding the wdt timeout) by the time I printed the RCON value. The solution there was to save RCON in a variable as my first line of code, then refer to that when I went to print. As has been pointed out, the ICD-2 does not allow you to have the watchdog timer enabled in the configuration bits. However, you CAN enable it in your runtime code with: WDTCONbits.SWDTEN=1; //enable wdt even if disabled in config bits This allowed the WDT to time out when I hit the while(1) and verify that my reset reporting code was working. Next is WHY was the wdt timing out? I turned off the WDT and let the system run. After several hours, the system stopped responding. So, the problem was definitely a crash (most likely an infinite loop), and not just too short a WDT period. Unfortunately, the ICD-2 will not do a halt on WDT timeout. So, I started the program again with the ICD-2 and waited for the system to stop responding. It eventually did. The program was hung waiting for a byte to finish transmitting on I2C. Looking at the I2C clock, I started the system where the byte was to be transmitted across I2C. Two clock pulses were visible, then the clock line got stuck about 100mV above ground. What's interesting (and I've seen this before with SPI also) is that the PIC apparently counts the clocks ON THE PIN rathern than before the pin driver. (Actually, I guess that make sense... the same circuitry can be used in slave mode). So, if the pin gets stuck the clock counter never advances and the BF flag never gets set. So, that's why the system was hanging. In this system, the PIC is the only I2C master, so no one else is supposed to drive the clock. Looking for the easiest thing to pull off the I2C bus, I found a plug in memory module that is custom made for this product. Unplugging it, all 8 I2C clocks appear, the system runs, and the WDT has not yet timed out after several hours of operation. So, stuff I learned: 1. You CAN run the WDT with the ICD-2. You just have to enable it in your code instead of the config bits. 2. RCON is useful! Check it early, as something may mess it up later. 3. Reminded that a stuck SPI or I2C clock will keep BF from going true. Again, thanks for the ideas! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available!

part 0 44 bytes his is a multi-part message in MIME format. part 1 344 bytes content-type:text/plain; charset=ISO-8859-1; format=flowed (decoded 7bit) > 3. Reminded that a stuck SPI or I2C clock will keep BF from going true. Hello, I've written my own I2C-Routines (for the hardware-module!) in PicBasic using all the appnotes and tips from the net. I do not wait too long for any action to take place (waiting for SSPIF), I use a timeout ! greetings part 2 478 bytes content-type:text/x-vcard; charset=utf-8; (decoded 7bit) begin:vcard fn;quoted-printable:Bernd R=C3=BCter n;quoted-printable:R=C3=BCter;Bernd org:Promaxx;Entwicklung adr;quoted-printable;dom:;;W=C3=BClferoder Stra=C3=9Fe 10;Hannover;Nds;30539 email;internet:spam_OUTbernd.rueterTakeThisOuTpromaxx.net title:Dipl.-Ing. tel;work:+49 511 3746207 tel;fax:+49 511 3746208 note:Meine Kontakte sammle und pflege ich in OpenBC: http://www.openbc.com/go/invite/3470477.7f1d19 url:http://www.promaxx.net version:2.1 end:vcard part 3 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)