This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Can excessive/intensive serial flow cause stack overflow?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]