| View previous topic :: View next topic |
| Author |
Message |
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
| WDT reset occurrence monitoring |
 Posted: Sun Feb 16, 2020 8:09 pm |
 |
|
Hi
I would like to monitor how many times a WDT reset occurred during the time the PIC is powered up in a variable.
I would like also to make the variable=0 on power-up.
I will send the variable to the PC so I can see how many times the WDT reset occurred.
I put the variable increment in the main:
| Code: | while(TRUE)
{
if(!bit_test(RCON,3))//TO~ bit; if '0', WDT timeout occurred
{
wdtlogger++;
}
restart_wdt();
} |
In the PIC18F26K22 page 60 is written:
| Quote: | RCON
bit 3 TO: Watchdog Time-out Flag bit
1 = Set by power-up, CLRWDT instruction or SLEEP instruction
0 = A WDT time-out occurred
bit 1 POR: Power-on Reset Status bit(2)
1 = No Power-on Reset occurred
0 = A Power-on Reset occurred (must be set in software after a Power-on Reset occurs) |
Checking the LST file, I didn't find where the POR reset bit is set so I can make wdtlogger=0; after then.
CCS PCH C Compiler, Version 5.062
Can somebody explain me the subject?
Best wishes
Joe |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Feb 16, 2020 10:59 pm |
|
|
You're supposed to use the restart_cause() function.
Look in the 18F26K22.h file in the section for restart_cause().
It lists the values (usually) returned by that function. |
|
|
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
|
| Posted: Mon Feb 17, 2020 12:29 am |
|
|
Thank you very much PCM programmer 
Helpful like always.
I didn't know CCS have this function.
I found in the examples ex_wdt.c, exactly what I need.
Best wishes
Joe |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Mon Feb 17, 2020 12:34 am |
|
|
The variable needs to be _global_.
If you have:
| Code: |
int wdt_count; //global and not initialised
void main(void)
{
intt cause;
cause=restart_cause();
if (cause!=WDT_RESET) //check the .h file for your processor for name
{
wdt_count++;
}
else
{
wdt_count=0; //initialise counter
}
//at this point wdt_count will be the count of watchdog wakes
|
You'll need to check the .h file to see what the watchdog restart is
clled on your processor. |
|
|
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
|
| Posted: Mon Feb 17, 2020 1:26 am |
|
|
Thank you Ttelmah.
I adapted ex_wdt.c, as below:
| Code: | switch(restart_cause())
{
case WDT_TIMEOUT:
{
fcpwdtlogger++;
fcpwdtresetF=1;//wdt timeout
}
break;
case NORMAL_POWER_UP:
{
fcpwdtlogger=0;
fcpwdtresetF=0;//powerup reset
}
break;
}
setup_wdt(WDT_16MS);//~16 ms reset |
If no, I will try your posted program.
Best wishes
Joe |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Mon Feb 17, 2020 1:37 am |
|
|
That looks good.
The reset names differ on different processor files, and I'm not on a
machine with the compiler at the moment.
If you actually want the machine to reset 'quickly' on a watchdog, you
can have the 'NORMAL_POWER_UP' code branch initialise all variables,
then the watchdog branch initialise only things you want to reset on
a watchdog. Declare variables uninitialised, and you can then carry on
with things unaffected by a watchdog restart. |
|
|
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
|
| Posted: Mon Feb 17, 2020 3:59 am |
|
|
Thank you Ttelmah.
Tested with the MPLAB Simulator, from power-up to inside "while" is 1ms if I have #ZERO_RAM before main.
I out-commented //#ZERO_RAM as I am giving default value to all the variables and then from power-up to inside "while" is 27us.
I think I will remain with //#ZERO_RAM.
Best wishes
Joe |
|
|
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
|
| Posted: Tue Feb 18, 2020 11:39 pm |
|
|
Hi
I tested for 5 hours and no any WDT reset occurred.
I made the test to see if the Master or Slave hangs in the I2C
https://www.ccsinfo.com/forum/viewtopic.php?t=58095
Or the I2C never hangs, or my testing is not correct.
I hope that my monitoring is correct
Best wishes
Joe |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19545
|
|
| Posted: Wed Feb 19, 2020 3:43 am |
|
|
Properly wired and driven, I2C should never hang.
However just occasionally a slave will miss a clock, or see an extra clock
(particularly in noisy environments), and in this case the master needs
to recover it by sending extra clocks till SDA releases.
Similarly infrequently the master can see an incorrect bus hold/release,
and in this case a master reset (WDT) is a good recovery.
Both only really apply either with a lot of EMI noise (motor/relay switching),
or with a master/slave that has a fault in it's bus handling. Both can
happen, but 'rarely'.
I have a unit here that has run I2C without a single packet problem
continuously, with 8640*64 byte transactions a day, for the last 12 years....
(it stores data into a rolling EEPROM buffer every 10 seconds). It uses
a 128K EEPROM, forming a circular buffer (index stored in SRAM), using
a 64byte block, so 256 records in the chip. So using 34 life cycles a day,
so predicted EEPROM life is about 80 years. It's been on 'long term test'
just to prove that this system will work reliably. There are four others
on sites across the country setup at the same time, and all have the
same reliability record.... |
|
|
gjs_rsdi
Joined: 06 Feb 2006
Posts: 468
Location: Bali
|
|
| Posted: Wed Feb 19, 2020 5:35 pm |
|
|
Hi Ttelmah
Encouraging to read that you didn't had problems for so long time with the I2C.
Taking in consideration that my 2*PIC and the EEPROM are very close each other on the same board, I think will have no problems
Best wishes
Joe |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
