This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Can excessive/intensive serial flow cause stack overflow?
- From: Alexandre <thekyz at gmail dot com>
- To: "eCos Mailing List" <ecos-discuss at ecos dot sourceware dot org>
- Date: Thu, 3 Jul 2008 11:57:50 +0200
- Subject: [ECOS] Can excessive/intensive serial flow cause stack overflow?
- Reply-to: thekyz at gmail dot com
Hi all,
Working on a new eCos application & I stumble upon a disturbing problem.
I'm working with eCos CVS on an LPC2106 platform with 2 UARTs.
I have two threads running at the same time:
- First one monitors serial requests coming to UART0,
- Second one supervise the operation of the first thread to prevent it
from blocking the system too much.
When a particular request occurs on UART0, the first thread writes
information on UART1. As information can flow really fast & UART0 line
(115200 bauds) is faster than UART1 (4800 bauds). I implemented a way
to tell the terminal making request to my UART0 to calm things a bit
if the UART1 buffer is full.
My problem is: this never happens, when the UART1 buffer is full, the
processor goes into prefetch abort and the watchdog eventually resets
everything.
The code to the first thread comes down to that (whiled):
***********************************************************************
len = rqst->byte_count;
// wake up the supervisor
cyg_cond_signal(&(hModbus->super.wake_up));
// write data to UART1
wErr = cyg_io_write(hModbus->hComT, rqst->data, &len);
// tell the supervisor we returned from write operation
cyg_cond_signal(&(hModbus->super.abort));
if(wErr != ENOERR) {
// write operation not fulfilled
// some action
}
// some other action
***********************************************************************
The supervisor (second thread):
***********************************************************************
while(1) {
cyg_mutex_lock(&(hModbus->super.wake_up_mutex));
// wait for wake up signal from serial monitor
cyg_cond_wait(&(hModbus->super.wake_up));
// start serial timed wait
cyg_mutex_lock(&(hModbus->super.abort_mutex));
state = cyg_cond_timed_wait(&(hModbus->super.abort), 1);
// time-out
if(state == false) {
len = 1;
cyg_io_get_config(hModbus->hCom,
CYG_IO_GET_CONFIG_SERIAL_ABORT, 0, &len);
len = 1;
cyg_io_get_config(hModbus->hComT,
CYG_IO_GET_CONFIG_SERIAL_ABORT, 0, &len);
}
cyg_mutex_unlock(&(hModbus->super.abort_mutex));
cyg_mutex_unlock(&(hModbus->super.wake_up_mutex));
}
***********************************************************************
I don't use any dynamic allocation in neither threads (never in this
program anyway) and can't see what can cause stack corruption here.
The 115200 UART0 line is stressed up to its maximum capacity and
causes those two threads to run at full speed.
What I'd like to know is if there would be any way for either of the
cyg_ functions I call to cause my problem:
- cyg_io_write(...)
- cyg_cond_signal(...)
- cyg_mutex_lock(...)
- cyg_cond_wait(...)
- cyg_cond_timed_wait(...)
- cyg_get_config(...)
- cyg_mutex_unlock(...)
I've read though the different documentations available & can't see a
way for these functions to cause stack overflow if called a lot.
Thank you very much for your time,
Alex
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss