CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
Error with ERRORS

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
malcolmst



Joined: 25 Oct 2004
Posts: 2

View user's profile Send private message

Error with ERRORS
PostPosted: Mon Oct 25, 2004 12:16 am     Reply with quote
Hello,

I am using the compiler with a PIC18F8720, and I'm having a problem when I use the ERRORS directive with USE RS232.

My application uses a WDT, since it has a wireless modem which will sometimes drop out, requiring a reset. Without the ERRORS directive, this will reset fine when necessary (but it will often not read the RS232 data). When I add the ERRORS directive, the data is fine, but it somehow prevents a WDT reset. If it hangs when waiting for data, it will never reset.

Can someone please explain to me exactly what ERRORS does, and if you have any ideas why it might be preventing a WDT reset (how I can make WDT still work)?

Thanks so much!
--Malcolm
Mark



Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA

View user's profile Send private message Send e-mail

PostPosted: Mon Oct 25, 2004 6:19 am     Reply with quote
Post your #use RS232 statement. Did you by chance include "RESTART_WDT". If you call getc() it will wait there forever until a char comes in.
Guest
PostPosted: Mon Oct 25, 2004 5:30 pm     Reply with quote
Hi Mark,

Here is the delay statement and RS232:

Code:

#use delay(clock=20000000, restart_wdt)
....
#use i2c(master,sda=PIN_C4,scl=PIN_C3,fast)
#use rs232(baud=4800, xmit=PIN_J0, rcv=PIN_J1, stream=gps)
#use rs232(baud=115200, xmit=PIN_G1, rcv=PIN_G2, stream=mainunit)
#use rs232(baud=115200, xmit=PIN_C6, rcv=PIN_C7, ERRORS, stream=modem) // This is the RS232 line with the issue


I am using getc() and fgetc(<stream>) to get the serial data.

Avatar kindly pointed out to me that it could possibly be in the delay statement. With the restart_wdt there, I think that is quite likely - I didn't notice it before Embarassed . I will try it without that and see what happens.

Thanks!
--Malcolm
malcolmst



Joined: 25 Oct 2004
Posts: 2

View user's profile Send private message

PostPosted: Tue Oct 26, 2004 2:06 am     Reply with quote
Hi Everyone,

Unfortunately, this does not solve the problem. I have tried many things, even dealing with the overrun manually. It still does not properly receive data. I also tried using RTS as a hardware flow control, but the overrun still happens. When the restart_wdt is removed from the #use delay, and ERRORS is kept in the #use rs232, it will still not reset when needed.

Any other ideas would be greatly appreciated.

Thanks!

--Malcolm
Ttelmah
Guest
PostPosted: Tue Oct 26, 2004 2:36 am     Reply with quote
malcolmst wrote:
Hi Everyone,

Unfortunately, this does not solve the problem. I have tried many things, even dealing with the overrun manually. It still does not properly receive data. I also tried using RTS as a hardware flow control, but the overrun still happens. When the restart_wdt is removed from the #use delay, and ERRORS is kept in the #use rs232, it will still not reset when needed.

Any other ideas would be greatly appreciated.

Thanks!

--Malcolm

How are you dealing with the overrun manually?. This should work. Are you clearing the framing error as well (this is supposed to be reset when you read the character, but I have had problems in the past with this not being cleared on the chips).
I'd suggest posting your RS232 receive code. What you are describing, suggests that there is a delay being called in the RS232 routine somewhere (perhaps not explicitly by you), which then results in the watchdog being reset, so long as RS232 data is being seen. My thought would be that if when the second unit fails, the RS232 line gets pulled permanently low (break condition), then this triggers continuous reads, with probably the _framing error_ set, and keeps the watchdog from resetting. Without 'errors', the error bit(s) gets set, killing the UART, which then stops receiving, and the watchdog occurs.

Best Wishes
Guest
PostPosted: Tue Oct 26, 2004 6:06 pm     Reply with quote
Thanks for your help everyone!

It turns out that in a certain point in the code, when a WDT occured, somehow it would cause a stack underflow, and start running some of the code generated by ERRORS.... So the errors option didn't directly cause the problem, but the problem only occured when the errors option was there.

I removed some code at that point which wasn't necessary, and it works fine now! Very Happy

--Malcolm
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group