Quote Originally Posted by Steve_88 View Post
Is the boot loader software really interfering with the WDT?
I guess it depends on the bootloader.

Before answering last time, I imported the Mecanique loader for the 18F252 into MPLAB, just to make sure.

On any reset, there is a period of time that the loader waits for activity from the USART. If it sees activity, it jumps to the bootloader, and if not, it times out and jumps to the user program.

During that period, it has to make sure the WDT doesn't timeout, so it uses the CLRWDT instruction.

When CLRWDT is executed, it sets the RCON TO (timeout) bit to 1, which means that no timeout has occurred. Anytime you want to catch a WDT reset, you have to do it at the very beginning of the program, before any CLRWDT instructions have been executed. But since the bootloader itself resets it, you can't.

I'm trying to use the WDT to escape from a SERIN command with timeout where the baud rate of the PIC and peripheral are different, maybe there is a better way?
There are 2 better ways that I can think of.

1. Use ICSP instead of a bootloader.

2. Use SERIN2. Set a very long timeout period in the SERIN2 statement. Then use interrupts with a timer for the timeout period.

When the timeout expires, clear the PBP system variable that is tracking the SERIN2's timeout. Which should cause the SERIN2 statement to terminate.

If you decide to go route #2, I can search through the library to find out which system vars to use. But I would suggest just using ICSP.

hth,

Added:

3. Don't use the bootloader. Which frees up the USART. Then use the USART for the serial communications.

If the USART is receiving data at a different baud rate than expected, it will throw a Framing Error immediately, so you don't need to worry about the timeout.