SOLVED - PIC seems to RESET unless I add a PAUSE in Mainloop

PIC 16F18877

Code:

---

#CONFIG
    __config _CONFIG1, _FEXTOSC_OFF & _RSTOSC_HFINT32 & _CLKOUTEN_OFF & _CSWEN_OFF & _FCMEN_ON
    __config _CONFIG2, _MCLRE_ON & _PWRTE_OFF & _LPBOREN_OFF & _BOREN_ON & _BORV_LO & _ZCD_OFF & _PPS1WAY_OFF & _STVREN_ON & _DEBUG_OFF
    __config _CONFIG3, _WDTCPS_WDTCPS_11 & _WDTE_ON & _WDTCWS_WDTCWS_7 & _WDTCCS_LFINTOSC
    __config _CONFIG4, _WRT_OFF & _SCANE_available & _LVP_OFF
    __config _CONFIG5, _CP_OFF & _CPD_OFF
#ENDCONFIG

DEFINE OSC 32

ANSELA = %00000000
ANSELB = %00000000
ANSELC = %00000000
ANSELD = %00000000
ANSELE = %00000000

TRISA = %00000000
TRISB = %00000000
TRISC = %00000000
TRISD = %00000000
TRISE = %00001000

LEDblink            var PORTD.0

    PAUSE 200
    LEDblink = 0

Mainloop:
    LEDblink = 1
'    PAUSE 1
    LEDblink = 0
'    PAUSE 1
  GOTO Mainloop
end

---

Any idea why it seems to reset unless I have a PAUSE 1 in Mainloop?

The trace is on LEDblink pin.

Attachment 9763


I had this PIC working a while ago. I don't see what I'm missing. :confused:

Yeah, had Port instead of Lat.

https://www.picbasic.co.uk/forum/sho...s-the-mainloop


I switched this to WDTE=OFF and it no longer resets.

(have some reading to do on WDTE)

Normally Watchdog is reset within the code PBP produces.

But why it does not in the case of 16F18877 seems strange. Maybe it is not controlled correctly?

Ioannis

I have no clue.

My PIC is either ON or OFF, I have no Sleep mode.

https://ww1.microchip.com/downloads/...Doc/31026a.pdf

Quote:

---

During normal operation, a WDT time-out generates a device RESET. If the device is in SLEEP mode, a WDT time-out causes the device to wake-up and continue with normal operation, this is known as a WDT wake-up. The WDT can be permanently disabled by clearing the WDTE configuration bit.

---

What is the duration of this reset, if it is reset?

You may add a PAUSE 1000 at the beggining of the program and see if this duration is increased. This will confirm that PIC is indeed reseting.

Ioannis

It is definitely a reset, a look at the lst file shows that the looped code segment has no pbp statements in it that generate a clwdt instruction

that loop does the the same thing for every pic chip i tried. its not really a practical loop more a curiosity

I was testing a new breadboard layout and PIC config; to make sure I had a heartbeat before piling more code.

Since on power up the SEN bit of the WDTCON0 register is at 0 (Watchdog disabled), why does that chip resets itself?

Ioannis

Because if the WDTE bits in CONFIG3 is anything but 0b01 the SEN bit is ignored and the CONFIG block of the code contains _WDT_ON which, according to the .INFO file for the device means

Code:

---

_WDTE_ON            ;WDT enabled regardless of sleep; SWDTEN ignored

---

If you want software control of the WDT you could choose

Code:

---

_WDTE_SWDTEN            ;WDT enabled/disabled by SWDTEN bit in WDTCON0

---

/Henrik.

But then I see no way that PBP is aware of that or can reset the WDT.

Ioannis

Quote:

---

Originally Posted by Ioannis

But then I see no way that PBP is aware of that or can reset the WDT.

Ioannis

---

I would guess by this bit?

Quote:

---

When the WDTE bits of Configuration Words are set to ‘01’, the WDT is controlled by the SEN bit of the WDTCON0 register.

---

(p. 163 of datasheet)

Basically the CONFIG settings allows you to force the WDT either on/off OR allow the program to turn it on/off at runtime.

As for resetting/clearing it, as long as you don't DEFINE NO_CLRWDT 1 PBP will clear/reset the WDT by inserting CLRWDT instructions into the code - it doesn't matter if the WDT is actually enabled, disabled, running or not. The instructions will be embedded in the assembly listing of the program. Unless, apparently, you do this kind of super tight loop.

Does it matter if it is a tight loop in PBP? If it was in assembly I could understand, but in Basic? Seems like a bug.

Ioannis

It's not a bug nor does it have any relationship to being a tight loop, the var=0 statement simply doesn't incorporate a clwdt instruction [quite correctly]. Any endless loop Consisting solely of that sort of statement will exhibit the same effect. It's not a practical program more a curiosity. If you just had to use it a two minute glance at the .lst file would reveal the issue, simply solved with an @ clwdt line or by disabling the wdt

Then what is the purpose of using a PBP compiler if it is not taking care of such cases?

I may want (and have needed in the past) very fast loops. It is the responsibility of the compiler to add that @clrwdt in between. Not mine. After all if I wanted to mess with assembly I would not use PBP, right?

That is why I see it as a bug.

Maybe I am wrong though...

Ioannis

PBP does handle it in, dare I say, >99% of cases. Here's one, fairly unrealstic case, where it doesn't.
I don't think PBP analyses the code in the details and determine exactly where to insert CLRWDT, I think it's more in line with what Richard says that the macros used by the various PBP statements either included a CLRWDT or they don't. When they get combined into a larger assembly listing it's "sprinkled" with CLRWDT instructions.

In this case the code resulted in assembly listing without any CLRWDT inserted. During >20 years of use I've never had that problem. That doesn't mean no one else have - apparently.

I mean, if you REALLY wanted to squeeze the most out of the PIC you'd turn off the WDT anyway in order to not waste time clearing it.

Out of curiosity, can you post an example of such a tight, endless loop, that you've used?

If compiler does not analyze this case then it is a problem. I really cannot remember having such a problem over my 25+ years of using PBP.

Will try to find that tight loop I tried many years ago when discussed it with Darrel and maybe it was on a F628 chip.

Will need time for this as it was long time ago...

Ioannis

Quote:

---

I may want (and have needed in the past) very fast loops. It is the responsibility of the compiler to add that @clrwdt in between. Not mine.

---

I disagree. If the compiler adds a CLRWDT in between every single instruction then there's no point in having it in the first place.
It's not going to detect a "fast loop" you make in your code.

I do understand fully. But also think there is a way compiler can detect that when needed. Sure it should not fill all over the place the CLRWDT!

Ioannis

The very famous R/W issue ?? :rolleyes:

try with High and Low commands instead and tell us what ...

Alain