WDTCLR_bit = 1; resets the microcontroller

[biljana.nedeljkovic]

Hello,

@serge87,
We will try to identify the problem as soon as possible. Thank you for the patience.

@phil31,
Since you already have a ticket as you mentioned, I think we should communicate via tickets, and in case you have a new problem or a discovery that you want to share, you can post here.

Kind regards,
Biljana

[Rotary_Ed]

I also have been bit by the failure of the MIKRO PIC32 Pascal compiler to handle the DEVCFG1.FWDTEN (Watch Dog Timer) bit properly.

For some reason it was not a problem when using the PIC32MX795F512H (64 pins) version of the chip. But, after switching to the PIC32MX795F512L (100 pins) version, my program kept resetting at around 18 minutes.

I finally noticed that no matter what configuration (enabled or disabled) selected for the WTD, the value for register DEVCFG1 did not change as it should have. I even went into the Scheme file and change the parameter value to "Disable", but it make no difference.

I finally resorted to inserting " ClrWdt(); //Reset Watch Dog Timer" into the main loop as a work-a-round and that stopped the reset at 18 minutes.

We really need to get this problem fixed.

Thanks

[ilferrari]

I also have been bit by the failure of the MIKRO PIC32 Pascal compiler to handle the DEVCFG1.FWDTEN (Watch Dog Timer) bit properly.

We really need to get this problem fixed.

Thanks

Don't worry, it has been on ME's to-do list since 2012, it will surely get done within the next few years.

[Rotary_Ed]

Well, I may not be around by the time they get around to it

I've tried "manually" setting/clearing the WTD On bit, the Windowed WTD bit, all to no effect.

The only thing that works for me in preventing the chip from resetting is inserting
ClrWdt(); into the code loop. Repeatedly clearing the timer

Still don't understand why I did not have that problem with the 64 pin version of the PIC32MX795F512H

[ilferrari]

Still don't understand why I did not have that problem with the 64 pin version of the PIC32MX795F512H

Maybe something to do with which reserved config bits use FWDTWINEN. You would have to try manually editing the hex output. The old PICKit app let you edit the bits manually, maybe others do aswell.

I have used a PIC32MX775F256H for a while and I noticed that the reserved config bits are all cleared by the compiler. While I haven't had a problem yet, Microchip's datasheets clearly specify that most reserved config bits should be left set, not cleared as the compiler does.

[Rotary_Ed]

Hard to say for sure, but I agree setting any default bits different than Microchip calls for is probably
not a good thing.

I finally fixed my problem with the WDT reset. I am using the MK USB bootloader (and since it is so
much quicker than the Programing Suite I use it all the time now), loading it to my chip using the programming
suite and then use the USB programmer to load my application code.

I finally went back and set the WTD timer configuration values for the bootloader code
to "Disabled", then I recompiled the bootloader code, loaded it to the PIC32Mx795F512L.
Then compiled the application code with the WTD disabled and using the USB bootloader tool,
loaded the application code to the chip.

So far- after running all night- the board has not reset.

I am also using the suggested in code configuration suggested by others:
WDTCONSET := 0; // Disble Watch Dog Timer
WDT_WIN_OFF_bit:= 0; // Turn off Windowing of Watch dog Timer
WDTCLR_bit := 1; // Clear the Watch dog timer
WDT_ON_bit := 0; // turn off watch dog timer

However, for me these setting did nothing to stop the WTD reset, Until I also disabled the WDT in the
bootload code

I am going to see if I can eliminate some of the above settings now that the bootloader code has its
configuration with WTD disabled.

[Rotary_Ed]

Well, it looks like I found something regarding using a bootloader and configuration bits in microchp document PIC32 Bootloader ...AN1388 013888.pdf. that may be of interest.

HANDLING DEVICE CONFIGURATION BITS
The bootloader does not erase or write the device Configuration words while programming the new application firmware. This is because the device Configuration words settings are shared by both the bootloader and the user application . Any modification to the device Configuration words may make the bootloader non-functional. Therefore, it is highly recommended to have common device Configuration words settings for both the user application and the bootloader.

Now this all assumes the MK bootloader application complies with AN1388 and I have no way of knowing that.

But, in any case, my bootloader's Configuration file had WTD "Enabled" whereas my application program had the WTD "Disabled". When I also disabled the WTD in the bootloader configuration file - (as well as the application's configuration) then my WTD resets ceased to be an issue.

I think the reason is according to the Chip datasheet

If the FWDTEN configuration bit (DEVCFG1<23>) is set, WDT is ALWAYS enabled ....In this mode, the ON bit cannot be cleared in software... To disable the WDT in this mode, the configuration must be rewritten to the device

. So it appears that if the FWDTEN bit is set in the bootloader and then loaded to the chip, that if you try to disable the WTD in the application's configuration code that the chip considers this an attempt to clear it by software and refuses to comply. While going back to the bootloader configuration code loaded onto the chip and disabling the WTD before bootloading it - seems to remedy the WTD reset problem - at least in my case where I use a bootloader.

I also found I no longer needed to add the following settings to my application code and have commented them out:

// WDTCONSET := 0; // Disable Watch Dog Timer
// WDT_WIN_OFF_bit:= 0; // Turn off Windowing of Watch dog Timer
// WDTCLR_bit := 1; // Clear the Watch dog timer
// WDT_ON_bit := 0; // turn off watch dog timer

[ilferrari]

It's July 2017, and version 4 of the compiler still clears config bits which are supposed to be set in the datasheet (Reserved: Write as ‘1’)

[khiamer]

this issue is Very real, MIKROE should introduce a way to edit the configuration registers manually in code.
DEVCFG3 : $1FC02FF0 : 0xC7070000
DEVCFG2 : $1FC02FF4 : 0x00000151
DEVCFG1 : $1FC02FF8 : 0x008AC5A3
DEVCFG0 : $1FC02FFC : 0x110FF00F

but the solution is just orthodox, you cannot reset the PIC32MX795F512L MCU with this WDTCON.WDTCLR bit. I dont know if its an issue with silicon version, but there is something you can do which is equivalent to reset, turn the dem dog OFF. in your reset function then on again

I have the same problem with my PIC32MX795F512L, and I think I have a workaround for this problem.

9.3.1 Modes of Operation
The WDT has two modes of operation: Windowed and Programmable Windowed.
The Programmable Windowed mode can be enabled by setting the Watchdog Window
Enable (WDTWINEN) bit (WDTCON<1>). In Programmable Windowed mode, software can
clear the WDT only when the counter is in its final window before a period match occurs.
There are four window size options. This window is active when the timer counter is greater
than a predetermined value for each option. Any attempts to clear the WDT when the window
is not active will cause a device Reset. In Windowed mode, software can clear the WDT
anytime before the period match occurs.


but, it doesn't work ... I tried in all possible modes, so :

The problem still persists if I try using the commands to reset the WDT as: ClearWDT() or WDTCONSET = 0x01 or WDTCONbits.WDTCLR = 1 ) so I tried to switch off the WDT and then turn it ON again and it worked.

So, if you experience this problem this is what you should do:

1. Set the WDT OFF from the configuration bits

#pragma config FWDTEN = OFF // Watchdog Timer is OFF
#pragma config WDTPS = PS4096 // Watchdog Timer Postscale - 4 sec or your desired value


2. During startup turn ON the WDT (I used the following with plib.h included but I think the WDTCONSET=0x8000 might work also)
EnableWDT () ;

3. During code execution, when you want a WDT reset just turn it OFF and ON again
DisableWDT () ;
// here i tried to insert the ResetWDT() command and it still resets the device
EnableWDT () ;

and that's it...

[Masterok_78]

Thanks you all, guys !!!

You made the useful great work !

But MIKROE comand is shown a bad side themselves, because only sometimes solve a problems, which there in production of MicroE And,also, there is no updates since 2016 year. It's very strange


Best regards to all !!!