Console problem update

Etienne Fortin etienne.fortin at sensio.tv
Fri Nov 5 15:01:23 UTC 2004


Hmmmm, quite interesting... I assumed that by default no flow control
was used... The problem is I put a breakpoint in termios.c where the
XON/XOFF characters should be sent and the breakpoint is never reached.
I'll clear c_iflag and test.

Thanks a lot,

Etienne


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


Etienne,

a baud rate difference of 2% is still tolerable, as 
fas as I know. And you would be well below.

I just had another look into the data structure 
snapshot you sent this morning (last night...). To 
my suprise, the "flow_ctrl" fiels is non-zero. The 
value 512 means, that the "input is controlled with 
XON/XOFF protocol". Maybe you should try to clear 
the "IXON" and "IXOFF" flags in the c_iflag field of 
termios settings?

wkr,
Thomas.


> Hi Thomas,
> Yes, the buffer is empty. But, it shows that at least 1161 characters 
> were received. After that, termios thinks there's no more data 
> received or it lost sync or something else.
> 
> I said before that my baudrate is really 9630 and not 9600. The 
> computer is 9600. Do you think that can be the problem?
> 
> Etienne
> 
> 
> 
> -----Message d'origine-----
> De : Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de]
> Envoyé : 5 novembre, 2004 02:23
> À : Etienne Fortin
> Objet : RE : RE : Console problem update
> 
> 
> Etienne,
> 
> from the data you sent, the input and output buffer really is
> "empty", (for rawInBuf and rawOutBuf, "Head" and "Tail" have the 
> same values) but I guess you already saw this.
> 
> Which BSP are you using? Is it possible your console driver
> interrupt gets stuck, when there is a receive and transmit 
> interrupt pending at the same time?
> 
> wkr,
> Thomas.
> 
> 
> > 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\00
> 0"
> > }, 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
> > 
> > 
> 
> --------------------------------------------
> 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
> 
> 

--------------------------------------------
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





More information about the users mailing list