| View previous topic :: View next topic |
| Author |
Message |
theteaman
Joined: 04 Aug 2006
Posts: 98
|
| UART too fast stops everything |
 Posted: Thu Aug 31, 2006 8:08 am |
 |
|
Hi there
When I send data at fast rates from my PC uart to the PIC uart, the PIC crashes. The reason I know the PIC crashes is because I always leave one of the PIC IO pins powering an LED, and at the point of the crash, the LED turns off...
I thought it might be because of a buffer overrun but that wouldnt explain the LED turning off would it? Also I added the 'ERRORS' directive to the use rs232 statement to stop any 'blocking' but that still didn't fix the crash.
My rs232 statement is:
| Code: | | #use rs232(baud=57600, xmit=PIN_C6, rcv=PIN_C7, PARITY=E) |
I know the code is working otherwise because when I introduce a 400ms delay after every 256 or so bytes, there is no crash. Its only when I don't have this delay.. can someone help? thanks |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Thu Aug 31, 2006 8:32 am |
|
|
Assuming you do NOT have the WDT enabled, I would look elsewhere for the problem. Something to do with your ring buffer pointer management.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
theteaman
Joined: 04 Aug 2006
Posts: 98
|
|
| Posted: Thu Aug 31, 2006 8:56 am |
|
|
| asmallri wrote: | | Assuming you do NOT have the WDT enabled, I would look elsewhere for the problem. Something to do with your ring buffer pointer management. |
Nah I dont have WDT enabled. My communication works basically like this:
- send 256bytes from PC to PIC
- PC then delays (X ms)
- during this delay the PIC does whatever it has to do
this process is repeated from about 30 * 256bytes.
etc..
For this reason it seems not to be the ring buffer (because I dont have one). The greater the value of X, the less chance of the PIC crashing.. but is crashing a sign of a buffer overflow?? |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Thu Aug 31, 2006 9:20 am |
|
|
yes.
Without the errors argument in the #use rs232 an overflow will
stop reception and that will look like the PIC stopped.
Either put in "errors" in the #USE rs232
ie
#use rs232(baud=19200,xmit=PIN_B3,invert,errors,stream=DEBUG)
((((note this isn't a great example because errors param isn't applicable to software serial)))
but the syntax is ok
or
check it/handle it by hand.
16F877
| Code: | #bit RCIF=0x0C.5
#bit CREN=0x18.4
#bit OERR=0x18.1
#bit FERR=0x18.2
#byte RCREG=0x1A
...
if (OERR){
bit_set(ERRORS,0);//let someone know overflow happened
CREN = 0;
delay_cycles(1);
CREN = 1;//clear the overflow
}
|
|
|
|
theteaman
Joined: 04 Aug 2006
Posts: 98
|
|
| Posted: Thu Aug 31, 2006 5:19 pm |
|
|
Thank you, but a blocking UART shouldnt cause all the PIC IO pins to output low should it? - an LED I have lighted suddenly switches off. I tried the errors directive but it still happens  |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Thu Aug 31, 2006 5:46 pm |
|
|
| As always, post a small but complete program that demonstrats the problem. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Fri Sep 01, 2006 3:09 am |
|
|
| theteaman wrote: | | Thank you, but a blocking UART shouldnt cause all the PIC IO pins to output low should it? - an LED I have lighted suddenly switches off. I tried the errors directive but it still happens |
Outputs can only change state when your program is misbehaving and writes data to the output port. The only other possibility I can think of is that the pin is no longer an output but changed to an input, for example by a processor reset.
I don't know how you connected the LED, but are you sure the pin is still an output? If yes, then a LED connected from the positive power supply would light up.
Add some code at program startup to signal you the processor has (re)booted, for example by flashing a LED. |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Fri Sep 01, 2006 6:18 am |
|
|
| ckielstra wrote: | | theteaman wrote: | | Thank you, but a blocking UART shouldnt cause all the PIC IO pins to output low should it? - an LED I have lighted suddenly switches off. I tried the errors directive but it still happens |
Outputs can only change state when your program is misbehaving and writes data to the output port. The only other possibility I can think of is that the pin is no longer an output but changed to an input, for example by a processor reset.
I don't know how you connected the LED, but are you sure the pin is still an output? If yes, then a LED connected from the positive power supply would light up.
Add some code at program startup to signal you the processor has (re)booted, for example by flashing a LED. |
A reset would make the pin an input again but it should also execute the code which turns on the LED again. |
|
|
theteaman
Joined: 04 Aug 2006
Posts: 98
|
|
| Posted: Fri Sep 01, 2006 4:59 pm |
|
|
Good ideas, thanks. I'll also try to post some code but I need to get it smaller and simple to demonstrate the problem. thanks  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
