ex_wdt.c does not seem to work on PIC18F8720: why not?

[RKnapp]

Friends,

Has anyone tried to run watchdog example ex_wdt.c on an 8720 -- or on any target chip for that matter? I'm running CCS's "Minipicd8x20" 18F8720 demo board and compiler v3.185.

- It does appear to time out.
- But when it restarts, I don't get any reset_cause() return other than "normal power up." I would think it would cite "wdt timeout" as the reason.

2) What is the correspondence between the #fuses values like WDT128 and the millisecond values of earlier chips?

Thanks,

Robert

[PCM programmer]

[RKnapp]

PCM Programmer,

Thanks for your reply, and for trying it on your board.

Mine still does not work! I tried the exact same code as yours except:

- my include file is the device file for 8720, "18F8720.h"

- #fuses XT is, in my code, #fuses HS. (I don't know what the different kind of clock arrangements are, and don't know how to find out what CCS means by these different options, but I think their protoboard can use only "HS", a 20MHz oscillator between pins 49 & 50, as a supplied timing source.)

- I'm not sure what our hardware differences would be; I'm using CCS v3.185 on their prototyping board "Minipicd8x20".

But it still does not work. I will submit a tech support request, but have not had great luck with these so far. If you have any other ideas, or anyone else tries this with an 8720, pls let me know.

Thanks anyway,

Robert

[PCM programmer]

Post the .LST file that you got when you compiled my test program.
(I mean, the program, after you changed it for the 18F8720).
I'll compare it to the code generated for vs. 3.178.

[RKnapp]

PCM,

.LST is below. Alas, I don't know assembly so I don't see anything obvious. It must be some kind of "fuse?" (Whatever "fuses" are, they're not documented; CCS manual says "typical choices are" blah blah.. but I can't see any mention of what these would correspond to in the Microchip Data Sheet.)

Thanks!

Robert

[rwyoung]

[RKnapp]

rwyoung,

Thank you very much for pointing me to this area. I hadn't understood the "#fuses" concept of these bits. I'll take a closer look at the datasheet and see what I can suss out.

Again, thanks,

Robert

[PCM programmer]

After studying the ASM, I'm not sure what the problem might be.
At this point, if this was my problem, I would put several printf
statements into the program, and display the value of the RCON
register at various points.

I also noticed that you have the DEBUG fuse set. I don't have it
set in my test program. I wonder, are you running your program
under ICD2 in Debug mode ? I don't know what effect that would
have, but it might be important. I did my test as a standalone
program, and programmed the 18F458 with my PicStart-Plus.

If you want to pursue this and use printfs to display RCON,
then you need to put the following line of code above main():

#byte RCON = 0xFD0

Then, within the program, you need to insert several statements
like these, at the appropriate points:

printf("initial RCON value = %x\n\r", RCON);

printf("RCON after setup_wdt() = %x\n\r", RCON);

printf("RCON after restart_wdt() = %x\n\r", RCON);

printf("RCON after getc() = %x\n\r", RCON);

Then run the program and let a Watchdog timeout occur,
(by not pressing a key), and see what values are displayed.
Then analyze them while referring to the data sheet.

[TSchultz]

Here are the fuse setting I normally use for PIC18 series parts with watchdog timer enabled, > 4MHz clock, and 5V supply.

#fuses HS, PUT, BROWNOUT, WRT, NOWRTD, WDT, WDT128, STVREN, BORV42, NOLVP

The biggest one is the WDT, this enables the watchdog timer. This is different than how the PIC16 series parts handle this. The WDT128 sets the watchdog prescaler to 128.

[RKnapp]

Friends,

Thanks for your attempts to help! I still can't get this thing to work; it must be some dumb thing. I'm running CCS v3.185, connected to an ICD-U40 v1.20, on CCS's 18F8720 prototyping board called "Minipicd8x20".

0) First of all, I can't figure out how to get the board to run independently of the ICD-U40: I'd sometimes like it in "programming" mode but not in "debug" mode. How is this done? As PCM noted, this could be important.

1) The "DEBUG" bit per se, however, appears to only to dedicate B6 & B7 to the interface if the 8720's .pdf, "PIC18F8xx20", page 245 (document page 243) re bit 7 of Config4L Bit 7, is to be trusted.

However, in any case, I cannot get this bit "un-set." There is some kind of error which pops up saying that ICD=TRUE must be in the #devices statement. However, whether in or out, this bit stays set... (?)

2) Now, I did try the suggested fuses

#fuses HS, PUT, BROWNOUT, WRT, NOWRTD, WDT, WDT128, STVREN, BORV42, NOLVP

but it immediately whined, saying "need #use delay if RS232 is to be used." So I added to this set:

#use delay(clock=20000000, RESTART_WDT)

but this did not appear to help, either.

3) I noticed that fuse WDT somehow does NOT lead to bit 0 of Config2H being set. My .lst file says, for the #fuses above:

Configuration Fuses:
Word 1: 2200 HS NOOSCSEN
Word 2: 0E04 NOBROWNOUT WDT128 NOWDT BORV42 PUT
Word 3: 0183 NOWAIT MCU CCP2C1
Word 4: 0001 STVREN DEBUG NOLVP
Word 5: C0FF NOPROTECT NOCPD NOCPB
Word 6: E0FF NOWRT NOWRTD NOWRTC NOWRTB
Word 7: 40FF NOEBTR NOEBTRB

Thus I conclude that WDTEN is not set, and that the WDT is under SWDTEN control. Is this material? Should this affect the call to tickle the watchdog, the example's restart_wdt (); call which turns into CLRWDT?

I.e., should I be directly trying to write the SDWTEN bit?

This must be simple.... maybe just detaching the ICD-U40 from the proto-board for standalone operations? I can't figure out if the plot is getting thicker or thinner here.

Robert

[RKnapp]

AHA! A break in the case: I think I've figured out how to run the board in "standalone" mode, and when I was able to do this, for some reason the WDT works fine -- and timeouts lead to the WDT_TIMEOUT reason.

0) I'd tried to talk directly to the ICD-U40 before, but the "control" always came up in ICD-S, not ICD-U mode (showing a little screen with COM1 and COM3 as the only possible choices. This is not good since it's a USB-based device.) I was annoyed at this but didn't want to click on either COM1/COM3 in case this would somehow confuse the IDE's Debugger -- which hasn't been confused before -- into wrongly thinking that I have an ICD-S. (When in doubt, never tempt Windows into serving up new annoyances.)

1) But finally I did try to click on COM1 just for the heck of it -- and after it greyed out for a while it came back offered the right choice, an ICD-U40. I clicked on this and a fancy graphical screen showing a board, an ICD, and a PC popped up!

2) Well shucks, this "ICD Control" screen offers lots of nice choices that do NOT involve debugging. You can update the ICD's firmware to 1.23 (the latest version), download .COFF files to the target, start/stop. When just "run" as a program, somehow, the WDT works fine and cites the correct restart_cause() value.

Fuses are still mysteriously set to NOWDT (indicating SWDTEN is still in charge) and I would love to know how this all works, if anyone knows -- but I guess I can't argue with success.

I'm posting this to THANK everyone who has wondered what is going on: Standalone ops are required for the WDT and ex_wdt.c to work correctly.

Robert