LuaRPC on LM3S Connection Issue (was Re: eLua-dev Digest, Vol 35, Issue 41)
Locked
|
On Fri, Jun 17, 2011 at 10:40 AM, Raman Gopalan <[hidden email]> wrote:
> > Hello, >> >> What's odd here is that I did hook up a scope to both Rx and Tx lines >> and at least at the MCU it appears to be sending back the initial >> handshake reply. > > Sure, I too was able to confirm this with stub code. You've been able to receive data from the MCU during this exchange using some alternate code? What's especially weird for me is that at least with what's opened and set up using the serial layer in LuaRPC it never seems to get _anything_ even if I double-send the header back. I would presume that the serial layer were broken in general on Windows, since I can use TeraTerm to use the eLua shell, but STM32 works fine. > >> >> What I can't figure out is why it never appears in >> the buffer in Windows. There's plenty of buffer space allocated >> beforehand. One difference I notice in timing between POSIX and >> Windows is that it seems to send the connection request byte and >> header as one "packet" whereas with windows there is a couple >> millisecond delay between the sending of the connection request byte >> and the 8 header bytes. Additionally, there appears to be a longer >> delay in responding to the single 9 byte POSIX send vs the separated >> Windows 1 + 2ms + 8 byte send. I haven't looked at timing on an STM32 >> platform yet to see how it differs if at all but I wonder if this >> might be related to timing? > > Certainly, there is a very good possibility of the problem emanating from > the > delta delay. I have also obtained "MY ERROR: header exchange failed" in > addition to the "no data received when attempting to read" error. The header exchange error is interesting, that indicates that it is reading something back. Have you experienced that only on one particular platform or another? > > I have also tried building on Gnu/Linux. The response is identical. The > ./luarpc > instance, while executing rpc.connect("/dev/ttyUSB0") takes me to an > infinite > waiting state. (Despite its posix compliance, which was tested successfully > on mac ?) Could you let me know which version of Linux you're using? It does work for me on Ubuntu x86_64 11.04. jsnyder@erlanger:~/Sources/elua$ ./luarpc test/test-rpc.lua Platform: LM3S CPU: LM3S6965 Board: EK-LM3S6965 CPU Clock: 50 MHz Memory Used: 7.759765625 kB jsnyder@erlanger:~/Sources/elua$ uname -a Linux erlanger 2.6.38-10-generic #44-Ubuntu SMP Thu Jun 2 21:32:22 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Also here's some stuff that was dumped into the system logs when the kernel was initializing the device: [10211.120029] usb 8-1: new full speed USB device using uhci_hcd and address 3 [10211.351617] usbcore: registered new interface driver usbserial [10211.351632] USB Serial support registered for generic [10211.351695] usbcore: registered new interface driver usbserial_generic [10211.351697] usbserial: USB Serial Driver core [10211.355645] USB Serial support registered for FTDI USB Serial Device [10211.355856] usb 8-1: Ignoring serial port reserved for JTAG [10211.355897] ftdi_sio 8-1:1.1: FTDI USB Serial Device converter detected [10211.356108] usb 8-1: Detected FT2232C [10211.356111] usb 8-1: Number of endpoints 2 [10211.356113] usb 8-1: Endpoint 1 MaxPacketSize 64 [10211.356115] usb 8-1: Endpoint 2 MaxPacketSize 64 [10211.356117] usb 8-1: Setting MaxPacketSize 64 [10211.358470] usb 8-1: FTDI USB Serial Device converter now attached to ttyUSB0 [10211.358498] usbcore: registered new interface driver ftdi_sio [10211.358500] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver It'd be interesting if you've got a different version or perhaps got a different packet size configuration? > > Have you encountered this before ? Not on Linux, but I have also done most of my testing and evaluation on OS X. I'd like to be able to reproduce this one on Linux as well since that would help narrow things down. I did try lengthening the delay on the server side for sending a reply back, but that doesn't seem to make any difference. It also doesn't seem to get anything if I try sending additional copies of the header or arbitrary data, the read in Windows just comes back empty regardless. This makes me wonder if something is broken in the state with the windows driver at the time the data is sent, or perhaps one of them isn't playing precisely by the rules in terms of physical/RS-232 state? Regarding your Linux setup, is the version of Linux you're running native or in a VM under windows? Is the 32 or 64 bit and which OS/kernel version might you be running? I wonder if you're having the same issue under both or if there are different issues going on here? >> >> It has definitely worked in the past on this platform. I may start >> trying to find the last working version and then use git bisect to >> find what change caused the current problem. > > Awaiting your response. One other quick note: replying to digests might make this thread a bit difficult to follow in the future. If you're wanting to continue using digests for replies, might I suggest trying something like Nabble: http://elua-development.2368040.n2.nabble.com/ It makes this list appear like a forum and even will allow you to subscribe to individual conversations. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
>
> Hello, >> >> What's odd here is that I did hook up a scope to both Rx and Tx lines >> and at least at the MCU it appears to be sending back the initial >> handshake reply. > > Sure, I too was able to confirm this with stub code. Hello, You've been able to receive data from the MCU during this exchange using some alternate code? I was able to confirm that the rx and tx on the micro-controller are working fine. What's especially weird for me is that at least with what's opened and set up using the serial layer in LuaRPC it never seems to get _anything_ even if I double-send the header back. I would presume that the serial layer were broken in general on Windows, since I can use TeraTerm to use the eLua shell, but STM32 works fine. When I wrote a few extra lines of code to retransmit the header received, the micro-controller only transmitted a string of '#'. At this point, I suspected the PC side transmit module. (./luarpc instance). Here I was certain that the bug was not relevant in the Elua domain. Would you agree with my conclusion ? > >> >> What I can't figure out is why it never appears in >> the buffer in Windows. There's plenty of buffer space allocated >> beforehand. One difference I notice in timing between POSIX and >> Windows is that it seems to send the connection request byte and >> header as one "packet" whereas with windows there is a couple >> millisecond delay between the sending of the connection request byte >> and the 8 header bytes. Additionally, there appears to be a longer >> delay in responding to the single 9 byte POSIX send vs the separated >> Windows 1 + 2ms + 8 byte send. I haven't looked at timing on an STM32 >> platform yet to see how it differs if at all but I wonder if this >> might be related to timing? > > Certainly, there is a very good possibility of the problem emanating from > the > delta delay. I have also obtained "MY ERROR: header exchange failed" in > addition to the "no data received when attempting to read" error. ... [show rest of quote] The header exchange error is interesting, that indicates that it is reading something back. Have you experienced that only on one particular platform or another? Yes, it brings up an interesting point. I have experienced this only on Windows. On Gnu/Linux, it just takes me to a waiting state. One direct possibility for this might be the lack of FNDELAY in fcntl(fd, F_SETFL, 0); I am yet to confirm this in the source level. (serial/serial_posix.c). Is this the case ? > > I have also tried building on Gnu/Linux. The response is identical. The > ./luarpc > instance, while executing rpc.connect("/dev/ttyUSB0") takes me to an > infinite > waiting state. (Despite its posix compliance, which was tested successfully > on mac ?) Could you let me know which version of Linux you're using? It does work for me on Ubuntu x86_64 11.04. When I tried this just about a week ago, I was using Ubuntu Remix (netbook edition), 10.04, Lucid Lynx, Intel X86 I will try running it on a 10.10 box. Will keep you posted. jsnyder@erlanger:~/Sources/elua$ ./luarpc test/test-rpc.lua Platform: LM3S CPU: LM3S6965 Board: EK-LM3S6965 CPU Clock: 50 MHz Memory Used: 7.759765625 kB jsnyder@erlanger:~/Sources/elua$ uname -a Linux erlanger 2.6.38-10-generic #44-Ubuntu SMP Thu Jun 2 21:32:22 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux This is awesome. Can't wait for lrpc to work on my box. Also here's some stuff that was dumped into the system logs when the kernel was initializing the device: [10211.120029] usb 8-1: new full speed USB device using uhci_hcd and address 3 [10211.351617] usbcore: registered new interface driver usbserial [10211.351632] USB Serial support registered for generic [10211.351695] usbcore: registered new interface driver usbserial_generic [10211.351697] usbserial: USB Serial Driver core [10211.355645] USB Serial support registered for FTDI USB Serial Device [10211.355856] usb 8-1: Ignoring serial port reserved for JTAG [10211.355897] ftdi_sio 8-1:1.1: FTDI USB Serial Device converter detected [10211.356108] usb 8-1: Detected FT2232C [10211.356111] usb 8-1: Number of endpoints 2 [10211.356113] usb 8-1: Endpoint 1 MaxPacketSize 64 [10211.356115] usb 8-1: Endpoint 2 MaxPacketSize 64 [10211.356117] usb 8-1: Setting MaxPacketSize 64 [10211.358470] usb 8-1: FTDI USB Serial Device converter now attached to ttyUSB0 [10211.358498] usbcore: registered new interface driver ftdi_sio [10211.358500] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver It'd be interesting if you've got a different version or perhaps got a different packet size configuration? > > Have you encountered this before ? Not on Linux, but I have also done most of my testing and evaluation on OS X. I'd like to be able to reproduce this one on Linux as well since that would help narrow things down. I did try lengthening the delay on the server side for sending a reply back, but that doesn't seem to make any difference. I did play around with timeout. It didn't make a difference. It also doesn't seem to get anything if I try sending additional copies of the header or arbitrary data, the read in Windows just comes back empty regardless. This makes me wonder if something is broken in the state with the windows driver at the time the data is sent, or perhaps one of them isn't playing precisely by the rules in terms of physical/RS-232 state? Sure, but on those occasions when I obtained "Header exchange mismatch", I least suspected the driver. How do we proceed towards cornering the fault ? Regarding your Linux setup, is the version of Linux you're running native or in a VM under windows? Is the 32 or 64 bit and which OS/kernel version might you be running? I wonder if you're having the same issue under both or if there are different issues going on here? It was native, 32 bit, Kernel version: 2.6.2X. >> >> It has definitely worked in the past on this platform. I may start >> trying to find the last working version and then use git bisect to >> find what change caused the current problem. > > Awaiting your response. One other quick note: replying to digests might make this thread a bit difficult to follow in the future. If you're wanting to continue using digests for replies, might I suggest trying something like Nabble: http://elua-development.2368040.n2.nabble.com/ It makes this list appear like a forum and even will allow you to subscribe to individual conversations. Sure, will incorporate this protocol. Thanks. Awaiting your reply. Raman |
|
|
In reply to this post by jbsnyder
Hello, I tried building on Gnu/Linux Ubuntu, 10.10. 2.6.35-22-generic #33-Ubuntu SMP i686 GNU/Linux I only made a small change in the rpc-lua.py file to link with the ncurses library. There is no change in response. ./luarpc does not return the handle. Here too, it just waits on the console infinitely. Am I overlooking any additional configuration that is mandatory for the lrpc on my Linux box ? Awaiting your response. Raman |
|
|
A dmsg gave me the following information. usb 8-1: Detected FT2232C usb 8-1: Number of endpoints 2 usb 8-1: Endpoint 1 MaxPacketSize 64 usb 8-1: Endpoint 2 MaxPacketSize 64 usb 8-1: Setting MaxPacketSize 64 usb 8-1: FTDI USB Serial Device converter now attached to ttyUSB0 This was on Ubuntu, 10.10, i686, Kernel: 2.6.35-xx This was not displayed. So, ftdi_sio was not registered. [10211.358498] usbcore: registered new interface driver ftdi_sio [10211.358500] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver I am not sure why this is not happening, but is there a conclusion we can draw ? |
|
|
In reply to this post by raman
On Mon, Jun 20, 2011 at 7:00 AM, raman <[hidden email]> wrote:
> > Hello, > > I tried building on Gnu/Linux Ubuntu, 10.10. > 2.6.35-22-generic #33-Ubuntu SMP i686 GNU/Linux > > I only made a small change in the rpc-lua.py file to > link with the ncurses library. There is no change in > response. ./luarpc does not return the handle. Here > too, it just waits on the console infinitely. Are you having to link in ncurses in order to get it to work? I believe that for most modern unix platforms just linking against readline should work if a recent version is installed. On my Ubuntu box I installed libreadline5-dev I believe and linked against that for a readline library. I also just checked in a version that uses linenoise instead to eliminate those dependencies. This should work fine for Linux & OS X. There's not a full port of that library for Windows yet. All that said, I'm not sure if this would have any effect on the issue being encountered, but perhaps something strange is going on here. I believe I have had occasions at least on Windows where the timeouts don't seem to work correctly unless I have something within luarpc.c or one of the lower level layers print something like a debug statement. > > Am I overlooking any additional configuration that > is mandatory for the lrpc on my Linux box ? I don't believe so, but maybe something in the above might be relevant. > > Awaiting your response. On the windows side, I did find an issue that was preventing it from reading data, at least on my machine. I'm not sure why I've only experienced this with LM3S, perhaps it has to do with which FTDI chip is onboard? In any case by not setting the DTR control to disabled, and just leaving it in its default state (whatever that might be) it now works for me on Windows XP 32-bit: C:\elua>luarpc test\test-rpc.lua Platform: LM3S CPU: LM3S6965 Board: EK-LM3S6965 CPU Clock: 50 MHz Memory Used: 10.009765625 kB I finally narrowed it down by a simple test program in C that just sent the 9 byte opening sequence and then tried to read the 8 byte header back. Since I found this worked, I then started removing things that weren't in this test setup from serial_win32 until I found that applying this one setting ( dcb.fDtrControl = DTR_CONTROL_DISABLE; ) would even prevent the test program from successfully running until I had unplugged/replugged the USB interface. I'm guessing that for some reason, even though the DTR line wouldn't even be used in this case, changing its state is messing something up or maybe it's having the opposite effect of disabling DTR? Some more investigation is warranted. This leads me to another question for others on the list: has anyone been using either luarpc, mux or rfs with LM3S boards successfully prior to this fix? Bogdan, have you tried RFS or mux with an LM3S eval kit using the onboard FTDI JTAG/UART for a serial interface? > > Raman > > A dmsg gave me the following information. > > usb 8-1: Detected FT2232C > usb 8-1: Number of endpoints 2 > usb 8-1: Endpoint 1 MaxPacketSize 64 > usb 8-1: Endpoint 2 MaxPacketSize 64 > usb 8-1: Setting MaxPacketSize 64 > usb 8-1: FTDI USB Serial Device converter now attached to ttyUSB0 > > This was on Ubuntu, 10.10, i686, Kernel: 2.6.35-xx > > This was not displayed. So, ftdi_sio was not registered. > [10211.358498] usbcore: registered new interface driver ftdi_sio > [10211.358500] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver > > I am not sure why this is not happening, but is there a conclusion we can > draw ? It may be that it's just not printing the same information to the logs with the version of Ubuntu you're running. I can't imagine it's not running that driver since I think that provides the virtual UART functionality. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
On Tue, Jun 21, 2011 at 7:13 AM, James Snyder <[hidden email]> wrote:
Nope, never. This is very weird though, DTR_CONTROL_DISABLE always worked for me in the RFS server (I can't remember if I tested it with LM3S under Windows though). This might have something to do with the combined JTAG/UART interface that you're talking about, I have no idea how that is implemented internally. Glad it works, although I'm not sure that letting fDtrControl have whatever value it gets from the system is a good idea. Not that I have a better one :)
Exactly. Since it's printing "FTDI USB Serial Device converter now attached to ttyUSB0" you can be sure that the driver is there.
Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, Jun 21, 2011 at 1:44 AM, Bogdan Marinescu
<[hidden email]> wrote: > Hi, > > On Tue, Jun 21, 2011 at 7:13 AM, James Snyder <[hidden email]> > wrote: >> >> On Mon, Jun 20, 2011 at 7:00 AM, raman <[hidden email]> wrote: >> > >> > Hello, >> > >> > I tried building on Gnu/Linux Ubuntu, 10.10. >> > 2.6.35-22-generic #33-Ubuntu SMP i686 GNU/Linux >> > >> > I only made a small change in the rpc-lua.py file to >> > link with the ncurses library. There is no change in >> > response. ./luarpc does not return the handle. Here >> > too, it just waits on the console infinitely. >> >> Are you having to link in ncurses in order to get it to work? I >> believe that for most modern unix platforms just linking against >> readline should work if a recent version is installed. On my Ubuntu >> box I installed libreadline5-dev I believe and linked against that for >> a readline library. >> >> I also just checked in a version that uses linenoise instead to >> eliminate those dependencies. This should work fine for Linux & OS X. >> There's not a full port of that library for Windows yet. >> >> All that said, I'm not sure if this would have any effect on the issue >> being encountered, but perhaps something strange is going on here. I >> believe I have had occasions at least on Windows where the timeouts >> don't seem to work correctly unless I have something within luarpc.c >> or one of the lower level layers print something like a debug >> statement. >> >> > >> > Am I overlooking any additional configuration that >> > is mandatory for the lrpc on my Linux box ? >> >> I don't believe so, but maybe something in the above might be relevant. >> >> > >> > Awaiting your response. >> >> On the windows side, I did find an issue that was preventing it from >> reading data, at least on my machine. I'm not sure why I've only >> experienced this with LM3S, perhaps it has to do with which FTDI chip >> is onboard? In any case by not setting the DTR control to disabled, >> and just leaving it in its default state (whatever that might be) it >> now works for me on Windows XP 32-bit: >> >> C:\elua>luarpc test\test-rpc.lua >> Platform: LM3S >> CPU: LM3S6965 >> Board: EK-LM3S6965 >> CPU Clock: 50 MHz >> Memory Used: 10.009765625 kB >> >> I finally narrowed it down by a simple test program in C that just >> sent the 9 byte opening sequence and then tried to read the 8 byte >> header back. Since I found this worked, I then started removing >> things that weren't in this test setup from serial_win32 until I found >> that applying this one setting ( dcb.fDtrControl = >> DTR_CONTROL_DISABLE; ) would even prevent the test program from >> successfully running until I had unplugged/replugged the USB >> interface. I'm guessing that for some reason, even though the DTR >> line wouldn't even be used in this case, changing its state is messing >> something up or maybe it's having the opposite effect of disabling >> DTR? Some more investigation is warranted. >> >> This leads me to another question for others on the list: has anyone >> been using either luarpc, mux or rfs with LM3S boards successfully >> prior to this fix? Bogdan, have you tried RFS or mux with an LM3S >> eval kit using the onboard FTDI JTAG/UART for a serial interface? > > Nope, never. This is very weird though, DTR_CONTROL_DISABLE always worked > for me in the RFS server (I can't remember if I tested it with LM3S under > Windows though). This might have something to do with the combined JTAG/UART > interface that you're talking about, I have no idea how that is implemented > internally. Glad it works, although I'm not sure that letting fDtrControl > have whatever value it gets from the system is a good idea. Not that I have > a better one :) So, I think I've figured it out. If you look at the manual at least for the 6965 EK: http://www.luminarymicro.com/index.php?option=com_remository&func=download&id=448&chk=ceb37bdddb4dba7268d347df3d68fcf7&Itemid=591 BDBUS4 (which is used at DTR for the B UART used for serial communication) is labeled as being connected to SWO_EN (Serial Wire Out Enable). According to the manual: "The evaluation board supports the Cortex-M3 serial-wire output (SWO) trace capabilities. Under debugger control, the CPLD can route the SWO datastream to the virtual communication port (VCP) transmit channel. The debugger can then decode and interpret the trace information received from the VCP. The normal VCP connection to UART0 is interrupted when using SWO. Not all debuggers support SWO. Refer to the Stellaris LM3S6965 data sheet for additional information on the trace port interface unit (TPIU)." The following Ubuntu bug where someone mentions that their UART stopped working, and prints gibberish when OpenOCD is started. Presumably this is the serial wire output. The fix was to pull out some DTR/RTS toggling: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/655868 According to the FTDI manual, DTR is an "active low" signal, so if it were enabled by default I presume this SWO line would be held low. By explicitly disabling DTR, it goes high changing the logic for for the PLD. If you look at the schematic again, you'll see that the Tx line from the MCU goes through the debug PLD _before_ the FTDI chip. Presumably raising SWO_EN/DTR disables Tx, which would mirror what we've been seeing, replacing it with SWO data if that's available (which it isn't unless you have the debugger running). I certainly hear what you're saying regarding "it feels bad to ambiguously leave DTR in the state it was left in" but I think that TeraTerm either leaves it alone or enables it by default. Leaving it active (held low) should be the equivalent of telling the other device "I'm alive." You could do this by setting DTR_CONTROL_ENABLE instead of DTR_CONTROL_DISABLE. If you want DTR handshakes that's still available as a separate option. This might explain why I've seen setup examples like the following, where the option isn't between turning on handshaking or disabling DTR, but between handshaking and holding it in enabled state: http://stackoverflow.com/questions/824029/how-to-do-serial-communication-in-c-program/824083#824083 Additionally, we're not doing anything with its configuration on POSIX directly, and I'm not sure if it's sticky between sessions there or not. In any case, I think that pretty well explains the origins of the behavior we've seen. I'm just surprised that this hadn't come up until now. Side Note: I did do a partial merge with the other serial code when I was experimenting with this, so I think I could fairly easily merge our two disparate serial layers (well, they're not that different, but the mux/rfs version has timeouts passed with each read call, and I think the select/readable function has different behavior). I'm thinking that it might be nice to use the overlapped I/O on windows as mux/rfs does, plus then we could have only one version of the serial layer to maintain. Side Note 2: Also ran across a cross-platform RS-232 library with a similar but a bit more granular API (https://github.com/ynezz/librs232/blob/master/include/librs232/rs232.h) and Lua bindings, which could be nice: https://github.com/ynezz/librs232/ I think we're in fairly decent shape with our implementation at this point however, and it's not really doing hugely different things. I'm tempted, though, slightly because it's also MIT license and has tests :-) > >> >> > >> > Raman >> > >> >> > A dmsg gave me the following information. >> > >> > usb 8-1: Detected FT2232C >> > usb 8-1: Number of endpoints 2 >> > usb 8-1: Endpoint 1 MaxPacketSize 64 >> > usb 8-1: Endpoint 2 MaxPacketSize 64 >> > usb 8-1: Setting MaxPacketSize 64 >> > usb 8-1: FTDI USB Serial Device converter now attached to ttyUSB0 >> > >> > This was on Ubuntu, 10.10, i686, Kernel: 2.6.35-xx >> > >> > This was not displayed. So, ftdi_sio was not registered. >> > [10211.358498] usbcore: registered new interface driver ftdi_sio >> > [10211.358500] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver >> > >> > I am not sure why this is not happening, but is there a conclusion we >> > can >> > draw ? >> >> It may be that it's just not printing the same information to the logs >> with the version of Ubuntu you're running. I can't imagine it's not >> running that driver since I think that provides the virtual UART >> functionality. > > Exactly. Since it's printing "FTDI USB Serial Device converter now attached > to ttyUSB0" you can be sure that the driver is there. > Best, > Bogdan > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |