TR : RE : Console problem update

Thu Nov 4 21:26:12 UTC 2004

-----Message d'origine-----
De : Etienne Fortin [mailto:etienne.fortin at sensio.tv] 
Envoyé : 4 novembre, 2004 16:23
À : 'Thomas Doerfler'
Objet : RE : RE : Console problem update

Hi Thomas,
Yes a VERY nasty problem... It must have something to do with my
comprehension and the way I implemented the console driver... But, I was
able to make a lot of other things work before (I mean, the balance of
RTEMS) and I got nasty problem with RTEMS before. But that one is
special. Its so stupid! And I hate to work with transfer protocol. You
know you'll be able to make it work, you just don't know when...

Anyway, here's the snapshot of the rtems_termios_tty structure when the
semaphore get stuck.

$2 = {forw = 0x0, back = 0x0, refcount = 3, major = 1, minor = 0, isem =
436273159, osem = 436273160, cbuf = 0x80d542a4 "}", ccount = 0, cindex =
0, column = 0, read_start_column = 0, termios = {c_iflag = 9474, c_oflag
= 4294967230, c_cflag = 2237, c_lflag = 32768, c_line = 0 '\0', c_cc =
"\003\034\177\025\004\n\001\000\021\023\032\000\022\017\027\026\000\000"
}, vtimeTicks = 100, rawInBuf = {theBuf = 0x80d53a98 "", Head = 1161,
Tail = 1161, Size = 2048, Semaphore = 436273162},
rawInBufSemaphoreOptions = 0, rawInBufSemaphoreTimeout = 100,
rawInBufSemaphoreFirstTimeout = 0, rawInBufDropped = 0, rawOutBuf =
{theBuf = 0x80d543b0 "ransfer...\r\n\r\nC\006C.\r\nrawInBuf.Size =
2048\r\nPress a key to begin t", Head = 17, Tail = 17, Size = 64,
Semaphore = 436273161}, t_dqlen = 0, rawOutBufState = rob_idle, device =
{firstOpen = 0x17a2 <console_first_open>, lastClose = 0x17ea
<console_last_close>, pollRead = 0, write = 0x16dc
<console_interrupt_write>, setAttributes = 0x172c
<console_set_attributes>, stopRemoteTx = 0x174e
<console_stop_remote_tx>, startRemoteTx = 0x1778
<console_start_remote_tx>, outputUsesInterrupts = 1}, flow_ctrl = 512,
lowwater = 64, highwater = 96, rxTaskId = 0, txTaskId = 0, t_line = 0,
t_sc = 0x0, tty_snd = {sw_pfn = 0, sw_arg = 0x0}, tty_rcv = {sw_pfn = 0,
sw_arg = 0x0}, tty_rcvwakeup = 0}

As you can see, I "hardwired" the rawInBuf to be 2048 characters in
size. And surprisingly enough, the Head is at offset 1161. This mean
that I received the first 130 bytes packet (init packet) and some part
of the first data packet. But for some reason, termios lost sync and
lost all the next characters, stucking the semaphore and giving me
headaches :)

What do you think???

And by the way, you can't imagine how glad I am to have help from all of
you on RTEMS forum.

Etienne Fortin
Sensio

-----Message d'origine-----
De : Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de] 
Envoyé : 4 novembre, 2004 16:09
À : Etienne Fortin; rtems-users at rtems.com
Cc : rtems-users at rtems.com
Objet : RE : Console problem update

Etienne,

can you provide a snapshot of the termios data structures when 
your console input gets stuck? What values do the buffer 
pointers have for the raw input buffer?

What baud rate are you using currently?

What happens, if you write a simple application with two tasks, 
one sending a 1K buffer to the console, one receiving it, and 
putting the console into loopback mode (with a nice little wire 
between pin 2 and 3 of your serial connector)? Does it also hand 
in that case?

You really seem to have a nasty problem there... 

I have been using termios code for machine interfaces back with 
RTEMS version 4.0.0, and I never had similar problems...

wkr,
Thomas.

> I don'T know why I tought that even after releasing the sempahore, I
> was still stuck in the idle thread. To the contrary! Forcing the 
> release of the semaphore make the task continue to execute code and I 
> eventually get out of the code with an error (that's ok since the 
> semaphore was forced to be released so no valid data is there 
> waiting)...
> 
> The question now is why the code is not notified of new characters. Is
> it possible that the termios code, being designed for "human" 
> interraction (at least I presume), can't cope with sustained binary 
> data transfer and so I lost data and eventually the semaphore is 
> struck waiting for characters that will never come? Is it possible?
> 
> Etienne Fortin
> Sensio
> 
> 
> 
> 
> 
> -----Message d'origine-----
> De : Joel Sherrill <joel at OARcorp.com>
> [mailto:joel.sherrill at OARcorp.com]
> 
> Envoyé : 4 novembre, 2004 15:21
> À : Etienne Fortin
> Cc : rtems-users at rtems.com
> Objet : Re: Console problem update
> 
> 
> Etienne Fortin wrote:
> > Hello all, its me again, the console guy :)
> > 
> > Little update for the ones that have an interest, or wish to help me

> > on that matter.
> 
> Is your interrupt an RTEMS ISR or a raw one directly connected to 
> hardware?  If you do not go through the RTEMS ISR wrapper, you will 
> NEVER schedule out of an interrupt.
> 
> Also are you sure you are geting the serial port interrupts?
> 
> > I tricked RTEMS to release the semaphore at each clock tick to make 
> > sure the semaphore was the problem. And surprise surprise! It still 
> > hang in the idle thread!!!!!!!!!
> > 
> > Theory: My task/scheduler/... config is fu***d up. Anyone here
> > thinks
> > it can be possible? For what I know of the problem so far, it seems 
> > that as soon as the idle thread is entered, no other thread ever
gets 
> > executed... Really seems a config problem to me...
> > 
> > Idea someone?
> > 
> > Etienne Fortin
> > Sensio
> > 
> 
> 
> -- 
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel at OARcorp.com                 On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>     Support Available             (256) 722-9985
> 
> 

--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd- systems.de/pgp_keys.htm