Question about 16F876 USART

Michael88 · Joined: 31 Oct 2003 Posts: 6

Hi all,

I used " #use rs232 ( baud = 19200, xmit=pin_c6, rcv = pin_c7, errors) " to setup my com port. The problem is that if incoming data is too large, the receiver will be locked up. Even watchdog or reset_cpu() does not help. Any suggestion to release com port from locked up?

Thank you!

Michael

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

If you have the ERRORS directive in the #use rs232() statement,
then any overrun condition should be detected and cleared by the
code inserted by the compiler. If this is not happening, then post
a small test program that shows the problem. Keep the program
very small. (Do not post a 200 line program). Show all #include,
#use, and #fuses statements. The program should be compilable
as posted.

Also post your compiler version. This will be a number such as
3.191, 3.236, or 3.249, etc.

Michael88 · Joined: 31 Oct 2003 Posts: 6

Thanks PCM.

My compiler version is 3.072. like you said, I'd like to write a small test program to do more test. The hard thing is that problem happened in the filed maybe once a month or weeks. In my code, there are some operations like writting to the EEPROM and NVRAM. It most likely the problem happened during the NVRAM and EEPROM writting. I do not think the test code will be less than 200 lines.
What I do not understand is that even I used watchdog and reset_cpu(), it still does not work, unless I use a jump to reset cpu.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

How do you know for sure that the UART receiver is locking up ?
Have you tested this in your lab ? Can you duplicate the field problem ?

I'm wondering if it's something else. Does this unit run continuously
or is it turned on and off ? What sort of power supply is used ?
If the voltage dropped, potentially the PIC could act in a flaky manner.
That's why the BROWNOUT fuse would help to fix this problem. Do you
have it enabled ? Also, do you have the PUT fuse enabled ?

Another thing that can cause random lockups is a missing NOLVP fuse,
or a floating MCLR pin (i.e., no pull-up resistor), or the lack of bypass
caps on the Vdd pins.

One more thing -- I don't have PCM vs. 3.072. I do have vs. 3.068.
I installed it and looked at the code generated by the compiler to handle
overrun errors, and it's identical to the code in the latest version, 3.249.
So it's likely that 3.072 is the same. Here is the code for 3.068:

asmallri · Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia

Michael88 · Joined: 31 Oct 2003 Posts: 6

Thanks PCM and Andrew,

To PCM:

The reason that I think the UART receiver is locked up is that because everything (including timer, IO ports etc) works fine except UART. I tried to increase data flow by hundred times in my lab and duplicated the field problem in minutes instead of weeks in the filed.

This unit should run continuously all the time. We use battery plus charger supply the power. So the voltage should be no drop.

The FUSE I used in my code is
"#fuses HS,WDT,PUT,NOPROTECT,BROWNOUT,NOLVP,NOCPD,WRT"

I will check my code and hardware as your suggestions and do more test.
Thanks so much!

To Andrew,

I think you are right. I just know that I need disable interrupts when writing to on chip EEPROM.
Two tests I did this morning:
1, Turn off GIE before writting to the EEPORM and turn on again after writting. The problem is still there.
2, Turn off UART before writting to the EEPORM and turn on again after writting. Seems it works fine. So I will consider this as a temporary solution.

Maybe I did not explain my question about WDT clearly. When the problem happened, The WDT can reset the PIC, but the UART receiver is still locked up untill I used a jumper to hardware reset The PIC. So my question is why the code already restarted but UART was still locked up?

Thanks again!

Regards, Michael