From: Nate W <del...@gm...> - 2005-12-29 06:36:28
|
Using this little script: cat /dev/ttyS2 & echo "Testing" echo "1500 1500" >> /dev/ttyS2 echo "1500 1500" >> /dev/ttyS2 ...I can send data out via ttyS2, and get data back. This works, repeatedly. I also have a C program that opens /dev/ttyS2, writes to it, and reads from it, and that works. That problem is that after I kill the C program with control-C, /dev/ttyS2 stops working. If I run the script above, or just echo "foo" > /dev/ttyS2 at the command line, it just hangs. No data is sent over the serial port (the robostix blinks an LED when it receives data) and the echo command never returns. If I press control-C during the script, I get the following error message at the console: ./test-robostix: 11: cannot create /dev/ttyS2: Interrupted system call cat: /dev/ttyS2: Resource temporarily unavailable Nothing interesting shows up in /var/log/messages or dmesg. I'm not sure what version of the buildroot I was using when I built my kernel, but it wa= s built on Nov 19 so I'm guessing it's roughly 642. So it seems that terminating my C program with the serial port open leaves /dev/ttyS2 in a broken state. Is this a bug in the kernel, or should I ad= d some code to detect the control-C and clean up as it exists? Or, both? :) Is there a way to reset the serial port, other than rebooting? Any assistance would be much appreciated! -- Nate Waddoups Redmond WA USA http://www.natew.com/ <=3D=3D for nerds http://www.featherforum.com/ <=3D=3D for birds |
From: Craig H. <cr...@gu...> - 2005-12-29 06:46:12
|
On Dec 28, 2005, at 10:36 PM, Nate W wrote: > Using this little script: > > cat /dev/ttyS2 & > echo "Testing" > echo "1500 1500" >> /dev/ttyS2 > echo "1500 1500" >> /dev/ttyS2 > > ...I can send data out via ttyS2, and get data back. This works, > repeatedly. > I also have a C program that opens /dev/ttyS2, writes to it, and > reads from it, and that works. > > That problem is that after I kill the C program with control-C, / > dev/ttyS2 stops working. If I run the script above, or just echo > "foo" > /dev/ttyS2 at the command line, it just hangs. What does "cat /proc/tty/driver/PXA\ serial" say before and after? How about stty -F /dev/ttyS2? > No data is sent over the serial port (the robostix blinks an LED > when it receives data) and the echo command never returns. If I > press control-C during the script, I get the following error > message at the console: > > ./test-robostix: 11: cannot create /dev/ttyS2: Interrupted > system call > cat: /dev/ttyS2: Resource temporarily unavailable > > Nothing interesting shows up in /var/log/messages or dmesg. I'm not > sure what version of the buildroot I was using when I built my > kernel, but it was built on Nov 19 so I'm guessing it's roughly 642. Check the file /etc/gumstix-release > So it seems that terminating my C program with the serial port open > leaves /dev/ttyS2 in a broken state. Is this a bug in the kernel, > or should I add some code to detect the control-C and clean up as > it exists? Or, both? :) Is there a way to reset the serial > port, other than rebooting? > > Any assistance would be much appreciated! > |
From: Nate W <del...@gm...> - 2005-12-29 19:03:24
|
> > What does "cat /proc/tty/driver/PXA\ serial" say before and after? > How about stty -F /dev/ttyS2? Right after booting: # ./get-serialstate serinfo:1.0 driver revision: 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 CTS|DSR|CD|RI 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 2: uart:STUART mmio:0x40700000 irq:13 tx:0 rx:0 3: uart:HWUART mmio:0x41600000 irq:0 tx:9769 rx:20793 RTS|CTS|DTR # stty -F /dev/ttyS2 speed 9600 baud; -brkint -imaxbel After a short and successful conversation with the robostix: (note that my test script also calls stty so that changes a bit) serinfo:1.0 driver revision: 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 CTS|DSR|CD|RI 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 2: uart:STUART mmio:0x40700000 irq:13 tx:318 rx:246 3: uart:HWUART mmio:0x41600000 irq:0 tx:19277 rx:34310 RTS|CTS|DTR # stty -F /dev/ttyS2 speed 38400 baud; min =3D 1; time =3D 0; -brkint -icrnl -imaxbel -opost -isig -icanon After starting and control-C'ing my C program: (the stty settings change a lot) # ./get-serialstate serinfo:1.0 driver revision: 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 RTS|CTS|DTR|DSR|CD|RI 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 2: uart:STUART mmio:0x40700000 irq:13 tx:318 rx:246 RTS|DTR 3: uart:HWUART mmio:0x41600000 irq:0 tx:30394 rx:50672 RTS|CTS|DTR # stty -F /dev/ttyS2 speed 38400 baud; intr =3D M-}; quit =3D M-^?; erase =3D M->; kill =3D \; eof =3D M-^A; eol = =3D M-,; eol2 =3D M-^A; start =3D M-}; stop =3D M-^?; susp =3D M->; rprnt =3D M-*; w= erase =3D @; lnext =3D \; flush =3D ^C; min =3D 1; time =3D 0; -cread -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke After starting and control-C'ing the test script (and getting the 'interrupted system call' message I described earlier) # ./get-serialstate serinfo:1.0 driver revision: 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 RTS|CTS|DTR|DSR|CD|RI 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 2: uart:STUART mmio:0x40700000 irq:13 tx:318 rx:246 RTS|DTR 3: uart:HWUART mmio:0x41600000 irq:0 tx:36394 rx:54432 RTS|CTS|DTR # stty -F /dev/ttyS2 speed 38400 baud; intr =3D M-}; quit =3D M-^?; erase =3D M->; kill =3D \; eof =3D M-^A; eol = =3D M-,; eol2 =3D M-^A; start =3D M-}; stop =3D M-^?; susp =3D M->; rprnt =3D M-*; w= erase =3D @; lnext =3D \; flush =3D ^C; min =3D 1; time =3D 0; -cread -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke If I "stty -F /dev/ttyS2 sane" I can restore the tty settings (see below), but the serial port still doesn't work. # stty -F /dev/ttyS2 sane # stty -F /dev/ttyS2 speed 38400 baud; # ./test-robostix Power-cycling the robostix Sleeping two seconds to let the robostix boot Testing [it just hung, so I press control-C] ./test-robostix: 11: cannot create /dev/ttyS2: Interrupted system call cat: /dev/ttyS2: Resource temporarily unavailable # stty -F /dev/ttyS2 speed 38400 baud; min =3D 1; time =3D 0; -brkint -icrnl -imaxbel -opost -isig -icanon And one last time: # ./get-serialstate serinfo:1.0 driver revision: 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 RTS|CTS|DTR|DSR|CD|RI 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 2: uart:STUART mmio:0x40700000 irq:13 tx:318 rx:246 RTS|DTR 3: uart:HWUART mmio:0x41600000 irq:0 tx:55146 rx:78454 RTS|CTS|DTR /etc/gumstix-release: # cat /etc/gumstix-release DISTRIB_ID=3D'gumstix' DISTRIB_DESCRIPTION=3D'' DISTRIB_RELEASE=3D'648M' DISTRIB_CODENAME=3D'' BUILD_DATE=3D'Sat Nov 19 18:55:25 PST 2005' BUILD_HOSTNAME=3D'localhost.localdomain' -- Nate Waddoups Redmond WA USA http://www.natew.com/ <=3D=3D for nerds http://www.featherforum.com/ <=3D=3D for birds |
From: Craig H. <cr...@gu...> - 2005-12-29 19:31:25
|
On Dec 29, 2005, at 11:03 AM, Nate W wrote: > What does "cat /proc/tty/driver/PXA\ serial" say before and after? > How about stty -F /dev/ttyS2? > > Right after booting: > > # ./get-serialstate > serinfo:1.0 driver revision: > 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 CTS|DSR|CD|RI > 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 > 2: uart:STUART mmio:0x40700000 irq:13 tx:0 rx:0 > 3: uart:HWUART mmio:0x41600000 irq:0 tx:9769 rx:20793 RTS|CTS|DTR > # stty -F /dev/ttyS2 > speed 9600 baud; > -brkint -imaxbel Is your console on the HWUART? > After a short and successful conversation with the robostix: > (note that my test script also calls stty so that changes a bit) > > serinfo:1.0 driver revision: > 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 CTS|DSR|CD|RI > 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 > 2: uart:STUART mmio:0x40700000 irq:13 tx:318 rx:246 > 3: uart:HWUART mmio:0x41600000 irq:0 tx:19277 rx:34310 RTS|CTS|DTR > # stty -F /dev/ttyS2 > speed 38400 baud; > min = 1; time = 0; > -brkint -icrnl -imaxbel > -opost > -isig -icanon > > After starting and control-C'ing my C program: > (the stty settings change a lot) > > # ./get-serialstate > serinfo:1.0 driver revision: > 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 RTS|CTS|DTR|DSR| > CD|RI > 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 > 2: uart:STUART mmio:0x40700000 irq:13 tx:318 rx:246 RTS|DTR > 3: uart:HWUART mmio:0x41600000 irq:0 tx:30394 rx:50672 RTS|CTS|DTR > # stty -F /dev/ttyS2 > speed 38400 baud; > intr = M-}; quit = M-^?; erase = M->; kill = \; eof = M-^A; eol = M-,; > eol2 = M-^A; start = M-}; stop = M-^?; susp = M->; rprnt = M-*; > werase = @; > lnext = \; flush = ^C; min = 1; time = 0; > -cread > -brkint -icrnl -imaxbel > -opost -onlcr > -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke Hmm -- looks like your program slaughtered the termios somehow. Looks like flow control got turned on as part of that, but since there are no flow control lines for the STUART, you're never going to get a CTS, and so the UART is never going to send any more bytes out. Here's my guess as to what your C code looks like: struct termios foo; // Cleverly leave out filling the struct with tcgetattr() thereby leaving foo in a nasty state foo.c_iflag |= SOMESETTING; foo.c_oflag |= OTHERSETTING; cfsetispeed(&foo, B38400); tcsetattr(fd,TCSANOW,&foo); Am I right? Did you forget the tcgetattr() call? > After starting and control-C'ing the test script (and getting the > 'interrupted system call' message I described earlier) > > # ./get-serialstate > serinfo:1.0 driver revision: > 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 RTS|CTS|DTR|DSR| > CD|RI > 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 > 2: uart:STUART mmio:0x40700000 irq:13 tx:318 rx:246 RTS|DTR > 3: uart:HWUART mmio:0x41600000 irq:0 tx:36394 rx:54432 RTS|CTS|DTR > # stty -F /dev/ttyS2 > speed 38400 baud; > intr = M-}; quit = M-^?; erase = M->; kill = \; eof = M-^A; eol = M-,; > eol2 = M-^A; start = M-}; stop = M-^?; susp = M->; rprnt = M-*; > werase = @; > lnext = \; flush = ^C; min = 1; time = 0; > -cread > -brkint -icrnl -imaxbel > -opost -onlcr > -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke > > If I "stty -F /dev/ttyS2 sane" I can restore the tty settings (see > below), but the serial port still doesn't work. Well, I think at this point, you've sent data down the channel with the weird termios settings, and so the robostix is probably confused because it's been getting all kinds of control characters and stuff? I don't really know what the deal is once it's in the bad state -- I think that can be safely ignored if you figure out what's causing the problem in the first place, and avoid that. C |
From: Nate W <del...@gm...> - 2005-12-29 20:32:29
|
> > serinfo:1.0 driver revision: > > 0: uart:FFUART mmio:0x40100000 irq:15 tx:387 rx:0 CTS|DSR|CD|RI > > 1: uart:BTUART mmio:0x40200000 irq:14 tx:0 rx:0 > > 2: uart:STUART mmio:0x40700000 irq:13 tx:0 rx:0 > > 3: uart:HWUART mmio:0x41600000 irq:0 tx:9769 rx:20793 RTS|CTS|DTR > > # stty -F /dev/ttyS2 > > speed 9600 baud; > > -brkint -imaxbel > > Is your console on the HWUART? I don't have a serial console, I use ssh and bluetooth networking. > Hmm -- looks like your program slaughtered the termios somehow. > Looks like flow control got turned on as part of that, but since > there are no flow control lines for the STUART, you're never going to > get a CTS, and so the UART is never going to send any more bytes out. Shouldn't I be able to recover from that via stty at the command line? Restoring all of those settings doesn't fix the serial port. > Am I right? Did you forget the tcgetattr() call? I initialize all fields of the termios structure, so tcgetattr shouldn't be necessary. > > If I "stty -F /dev/ttyS2 sane" I can restore the tty settings (see > > below), but the serial port still doesn't work. > > Well, I think at this point, you've sent data down the channel with > the weird termios settings, and so the robostix is probably confused > because it's been getting all kinds of control characters and stuff? Even if the robostix is confused, shouldn't "echo "foo" > /dev/ttyS2" still work? > I don't really know what the deal is once it's in the bad state -- I > think that can be safely ignored if you figure out what's causing the > problem in the first place, and avoid that. Agreed; I'll work on the termios settings and see if that solves the proble= m. Thanks for your help! -- Nate Waddoups Redmond WA USA http://www.natew.com/ <=3D=3D for nerds http://www.featherforum.com/ <=3D=3D for birds |
From: Nate W <del...@gm...> - 2005-12-29 20:35:05
|
On 12/29/05, Nate W <del...@gm...> wrote: > > Am I right? Did you forget the tcgetattr() call? > > I initialize all fields of the termios structure, so tcgetattr > shouldn't be necessary. I just realized that you ARE right. Most of the c_cc array contains garbage, and that's just asking for trouble. I'll fix that, and the problem will probably go away. But I still think it's weird that I can't get the gumstix to even write to the serial port again. -- Nate Waddoups Redmond WA USA http://www.natew.com/ <=3D=3D for nerds http://www.featherforum.com/ <=3D=3D for birds |
From: Craig H. <cr...@gu...> - 2005-12-29 22:20:35
|
On Dec 29, 2005, at 12:34 PM, Nate W wrote: > On 12/29/05, Nate W <del...@gm...> wrote: > >>> Am I right? Did you forget the tcgetattr() call? >> >> I initialize all fields of the termios structure, so tcgetattr >> shouldn't be necessary. > > I just realized that you ARE right. Most of the c_cc array contains > garbage, and that's just asking for trouble. > > I'll fix that, and the problem will probably go away. But I still > think it's weird that I can't get the gumstix to even write to the > serial port again. I'm pretty sure that's because flow control is on, but the STUART can never see CTS because there's no CTS line. C |
From: Dave H. <dhy...@gm...> - 2005-12-29 06:47:54
|
Hi Nate, > That problem is that after I kill the C program with control-C, /dev/ttyS= 2 > stops working. If I run the script above, or just echo "foo" > /dev/ttyS= 2 > at the command line, it just hangs. No data is sent over the serial port > (the robostix blinks an LED when it receives data) and the echo command > never returns. If I press control-C during the script, I get the followi= ng > error message at the console: Hmmm. I seem to recall that I use Control-C to terminate the sertest progra= m. Could you try that? It doesn't have a Control-C handler, but it does use the termios calls to setup the serial port (i.e. no flow control, raw, etc). -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: David F. <dav...@ya...> - 2005-12-29 16:39:20
|
--- Nate W <del...@gm...> wrote: > So it seems that terminating my C program with > the serial port open leaves > /dev/ttyS2 in a broken state. Is this a bug > in the kernel, or should I add > some code to detect the control-C and clean up > as it exists? Or, both? > :) Is there a way to reset the serial port, > other than rebooting? > I can't think of a reason why you should not trap the ctrl-c. Outside of being able to close the port (which I think should happed by default) you can examine the state of the port prior to close. David. |
From: <th...@th...> - 2006-01-03 01:06:58
|
how do i get off this crap ass mailing list. It is filling up my webserver with pointless bullshit that i never read and dont care about. Thanks =) Daniel Kelly > > > --- Nate W <del...@gm...> wrote: > > >> So it seems that terminating my C program with >> the serial port open leaves >> /dev/ttyS2 in a broken state. Is this a bug >> in the kernel, or should I add >> some code to detect the control-C and clean up >> as it exists? Or, both? >> :) Is there a way to reset the serial port, >> other than rebooting? >> > > I can't think of a reason why you should > not trap the ctrl-c. Outside of being able > to close the port (which I think should > happed by default) you can examine the > state of the port prior to close. > > David. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Jony H. <gu...@j-...> - 2006-01-03 01:25:37
|
th...@th... wrote: > how do i get off this crap ass mailing list. > > It is filling up my webserver with pointless bullshit that i never read > and dont care about. Read one of said crap ass mails to the bottom. You'll find a link. Jony |
From: Craig H. <cr...@gu...> - 2005-12-29 22:20:06
|
On Dec 29, 2005, at 12:32 PM, Nate W wrote: >> Am I right? Did you forget the tcgetattr() call? > > I initialize all fields of the termios structure, so tcgetattr > shouldn't be necessary. "Many of the functions described here have a termios_p argument that is a pointer to a termios structure. This structure contains at least the following members: tcflag_t c_iflag; /* input modes */ tcflag_t c_oflag; /* output modes */ tcflag_t c_cflag; /* control modes */ tcflag_t c_lflag; /* local modes */ cc_t c_cc[NCCS]; /* control chars */" In other words, there might be other bits of the structure too. And you're also only setting VMIN and VTIME of c_cc and not the other elements of that cc_t array. I would try using cfmakeraw() or tcgetattr() to initialize the struct before you set its various elements, and use |= and &= instead of just =, it just seems more prudent. Also, set the speed using cfset[io]speed() instead of setting the bit in c_cflag: "(POSIX says that the baud speed is stored in the termios structure without specifying where precisely, and provides cfgetispeed() and cfsetispeed() for getting at it. Some systems use bits selected by CBAUD in c_cflag, other systems use separate fields, e.g. sg_ispeed and sg_ospeed.)" That might not be what the problem is, but I'd certainly check that first. >>> If I "stty -F /dev/ttyS2 sane" I can restore the tty settings (see >>> below), but the serial port still doesn't work. >> >> Well, I think at this point, you've sent data down the channel with >> the weird termios settings, and so the robostix is probably confused >> because it's been getting all kinds of control characters and stuff? > > Even if the robostix is confused, shouldn't "echo "foo" > /dev/ttyS2" > still work? I think the reason it's not sending is because the port's been put into flow control mode, and it's not seeing a CTS signal, because there is no CTS line on the STUART. >> I don't really know what the deal is once it's in the bad state -- I >> think that can be safely ignored if you figure out what's causing the >> problem in the first place, and avoid that. > > Agreed; I'll work on the termios settings and see if that solves > the problem. > > Thanks for your help! |
From: Nate W <del...@gm...> - 2005-12-30 05:57:24
|
On 12/29/05, Craig Hughes <cr...@gu...> wrote: > On Dec 29, 2005, at 12:32 PM, Nate W wrote: > > >> Am I right? Did you forget the tcgetattr() call? tcgetattr solved the problem, thanks again for your help! Nate Waddoups Redmond WA USA http://www.natew.com/ <=3D=3D for nerds http://www.featherforum.com/ <=3D=3D for birds |