NetDuino: Serial TX to board fails

[sweetlilmre]

Hi,

I've been playing with eLua 0.8 on the NetDuino (AT91SAM7X512 based).
The source builds and deploys successfully to the device and on reset I am able to see the eLua prompt, however typing any characters into the terminal echoes back a high ASCII character 'ÿ' (IIRC).

I switched to the 0.7 tag, built and deployed and this behaviour disappeared i.e. the terminal worked as expected.

I assumed that this had something to do with the new SERMUX code and tried:

1. disablng SERMUX, this resulted in zero terminal output / response. Perhaps I am doing it incorrectly?
2. using the mux server to communicate with the board as per the tutorial, this resulted in the mux server exiting with "error on select" when I typed characters into the terminal emulator.

So it would seem that possibly SERMUX is not the issue but that the fault lies at the board RX level?

Does anyone have suggestions on how to debug / proceed?

Thanks
-(e)

[BogdanM]

Hi,

On Mon, May 2, 2011 at 2:44 PM, sweetlilmre <[hidden email]> wrote:

Hi,

I've been playing with eLua 0.8 on the NetDuino (AT91SAM7X512 based).
The source builds and deploys successfully to the device and on reset I am
able to see the eLua prompt, however typing any characters into the terminal
echoes back a high ASCII character 'ÿ' (IIRC).

This happens most likely because of SERMUX.

 

I switched to the 0.7 tag, built and deployed and this behaviour disappeared
i.e. the terminal worked as expected.

I assumed that this had something to do with the new SERMUX code and tried:

1. disablng SERMUX, this resulted in zero terminal output / response.
Perhaps I am doing it incorrectly?

You also need to set CON_UART_ID to the ID of the serial interface used for the console (which should be the same value as SERMUX_PHYS_ID).

 

2. using the mux server to communicate with the board as per the tutorial,
this resulted in the mux server exiting with "error on select" when I typed
characters into the terminal emulator.

This wasn't supposed to happen. What OS are you using?

 

Does anyone have suggestions on how to debug / proceed?

1. Disable SERMUX (undefine BUILD_SERMUX)

2. Disable RFS (undefine BUILD_RFS)

3. Set CON_UART_ID properly (as explained above) and try again.

Best,

Bogdan

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[sweetlilmre]

Hi,

I had already tried your suggestions i.e.

1. CON_UART_ID set to 0 (as per the 0.7 build IIRC)
2. undefined BUILD_SERMUX
3. BUILD_RFS already undefined

I will test and try again when I get home to make sure I didn't miss anything.
Thanks for your quick response.

-(e)

[BogdanM]

On Mon, May 2, 2011 at 4:28 PM, sweetlilmre <[hidden email]> wrote:

Hi,

I had already tried your suggestions i.e.

1. CON_UART_ID set to 0 (as per the 0.7 build IIRC)
2. undefined BUILD_SERMUX

Also undefine all the other macros related to the serial multiplexer (they start with SERMUX_...)

 

3. BUILD_RFS already undefined

Are you sure? Check if you're not confusing it with BUILD_RPC. 

I will test and try again when I get home to make sure I didn't miss
anything.

Please let me know how it goes.

Best,

Bogdan

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[sweetlilmre]

Hi,

I rebuilt a clean build following your suggestions exactly and it worked!
I must have broken something last time. So now I have a working 0.8 build without sermux.

FYI: I am using mux.exe under windows XP (for the select failing issue).

As far as the weird character issue with SERMUX enabled, is this due to the muxing code on device or is it a fault? I'd like to get muxing working before I move onto other issues.

-(e)

[sweetlilmre]

Hi,

Some more info:

I've tried running mux in both modes with the same result, here is the verbose output from a test run in rfsmux mode:

D:\source\elua>mux rfsmux:d:\source\elua com2,115200,none com20 -v
Running serial transport on port com2 at 115200 baud (8N1)
RFS: using memory transport.
Sharing directory d:\source\elua
Starting service multiplexer on 1 port(s)
Changed service_id_out from -1(FFFFFFFF) to 209(D1).
Error on select, aborting program

The error occurs as soon as I type any character in my terminal program.
The terminal is connected to COM21 which is linked to COM20 via com0com.
It would seems that the service_id change is correct (virtual port 2 i.e. terminal?)

-(e)

[BogdanM]

On Mon, May 2, 2011 at 7:30 PM, sweetlilmre <[hidden email]> wrote:

Hi,

I rebuilt a clean build following your suggestions exactly and it worked!
I must have broken something last time. So now I have a working 0.8 build
without sermux.

Excellent. This is a good start :)

 

FYI: I am using mux.exe under windows XP (for the select failing issue).

As far as the weird character issue with SERMUX enabled, is this due to the
muxing code on device or is it a fault? I'd like to get muxing working
before I move onto other issues.

That is the serial multiplexer protocol at work, trying to communicate what virtual port it is using.

Best,

Bogdan

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Mon, May 2, 2011 at 9:52 PM, sweetlilmre <[hidden email]> wrote:

Hi,

Some more info:

I've tried running mux in both modes with the same result, here is the
verbose output from a test run in rfsmux mode:

D:\source\elua>mux rfsmux:d:\source\elua com2,115200,none com20 -v
Running serial transport on port com2 at 115200 baud (8N1)
RFS: using memory transport.
Sharing directory d:\source\elua
Starting service multiplexer on 1 port(s)
Changed service_id_out from -1(FFFFFFFF) to 209(D1).
Error on select, aborting program

The error occurs as soon as I type any character in my terminal program.
The terminal is connected to COM21 which is linked to COM20 via com0com.
It would seems that the service_id change is correct (virtual port 2 i.e.
terminal?)

Yes, the service_id change seems to be correct. Please try the sequence of steps below:

1. start your eLua board

2. start your terminal emulator on COM21

3. start the RFS multiplexer as above

4. reset your eLua board

If you're getting any input on the terminal emulator after step 4 above, try to input something and see if that works. If not, please let me know. The mux server was never tested on XP, only on Win7. Although I kinda doubt that's the problem. Are you by any chance on 64bit XP?

Best,

Bogdan

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Martin Guy]

On 2 May 2011 16:41, Bogdan Marinescu <[hidden email]> wrote:
> On Mon, May 2, 2011 at 4:28 PM, sweetlilmre <[hidden email]> wrote:
>> 1. CON_UART_ID set to 0 (as per the 0.7 build IIRC)
>> 2. undefined BUILD_SERMUX
>
> Also undefine all the other macros related to the serial multiplexer (they
> start with SERMUX_...)

Doy! Wouldn't it be better to be able to deactivate any BUILD_* option
and have them toggle the related ones for you?
Undefining the other names that an absent module uses helps catch
coding errors in the code and makes sure that the module really is all
gone.

   M
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[sweetlilmre]

BogdanM wrote

Yes, the service_id change seems to be correct. Please try the sequence of
steps below:

1. start your eLua board
2. start your terminal emulator on COM21
3. start the RFS multiplexer as above
4. reset your eLua board

If you're getting any input on the terminal emulator after step 4 above, try
to input something and see if that works. If not, please let me know. The
mux server was never tested on XP, only on Win7. Although I kinda doubt
that's the problem. Are you by any chance on 64bit XP?

Best,
Bogdan

Hi,

I'm on windows xp 32-bit.
I tried the steps above with the same result i.e. select fail
Interestingly enough, after doing this and then connecting my terminal program to the physical UART (COM2) I can now enter characters normally.

It would seem that the board has switched into console mode permanently? Perhaps this is causing the fault on the mux side?

Thanks
-(e)

[BogdanM]

On Tue, May 3, 2011 at 1:28 AM, Martin Guy <[hidden email]> wrote:

On 2 May 2011 16:41, Bogdan Marinescu <[hidden email]> wrote:
> On Mon, May 2, 2011 at 4:28 PM, sweetlilmre <[hidden email]> wrote:

>> 1. CON_UART_ID set to 0 (as per the 0.7 build IIRC)
>> 2. undefined BUILD_SERMUX
>
> Also undefine all the other macros related to the serial multiplexer (they
> start with SERMUX_...)

Doy! Wouldn't it be better to be able to deactivate any BUILD_* option
and have them toggle the related ones for you?

 

This was more of a "paranoid check" anyway, you shouldn't need to deactive anything else than just the BUILD_ option. But to answer your question: definitely, it would be better. I don't want to get into a #ifdef mess on the C side though, I'd rather continue on the configurator idea.

 

Undefining the other names that an absent module uses helps catch
coding errors in the code and makes sure that the module really is all
gone.

Absolutely. 

 

Best,

Bogdan

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Tue, May 3, 2011 at 8:09 AM, sweetlilmre <[hidden email]> wrote:

BogdanM wrote:
>
>
> Yes, the service_id change seems to be correct. Please try the sequence of
> steps below:
>
> 1. start your eLua board
> 2. start your terminal emulator on COM21
> 3. start the RFS multiplexer as above
> 4. reset your eLua board
>
> If you're getting any input on the terminal emulator after step 4 above,
> try
> to input something and see if that works. If not, please let me know. The
> mux server was never tested on XP, only on Win7. Although I kinda doubt
> that's the problem. Are you by any chance on 64bit XP?
>
> Best,
> Bogdan
>

Hi,

I'm on windows xp 32-bit.
I tried the steps above with the same result i.e. select fail
Interestingly enough, after doing this and then connecting my terminal
program to the physical UART (COM2) I can now enter characters normally.

It would seem that the board has switched into console mode permanently?
Perhaps this is causing the fault on the mux side?

This is definitely weird. The board doesn't automatically switch between sermux and console moe automatically; once you compile it with sermux enabled, it stays that way. It looks either like a build problem or a configuration problem. Please try to make a clean build; if that still fails, can you please send your platform_conf.h?

Best,

Bogdan

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[sweetlilmre]

BogdanM wrote

This is definitely weird. The board doesn't automatically switch between
sermux and console moe automatically; once you compile it with sermux
enabled, it stays that way. It looks either like a build problem or a
configuration problem. Please try to make a clean build; if that still
fails, can you please send your platform_conf.h?

Best,
Bogdan

Hi,

I am using the stock platform_conf.h from elua / src / platform / at91sam7x in HEAD (or 0.8).
I have tried several clean builds and the functionality is the same.
I will also compare the platform_conf.h against some other platforms tonight to see if there is any noticeable difference.

-(e)

[sweetlilmre]

Hi,

Some more debugging later:

I have compiled mux under VS2010 (which was pretty easy considering the nice clean code!).
Debugging it I was able to observe the following interesting behaviour:

After typing a character 'a' into the terminal, the first call to ser_select_byte() succeeds.
The vUART service becomes active for CON and service ID (D1) is sent to the board followed by 0x61 or 'a'.

Then ser_select_byte() is called again and things get weird.
WaitForMultipleObjects() returns immediately with a value of zero (which should be the rfs vUART) and finally GetOverlappedResult() succeeds but reads zero bytes.

This causes a return of -1 from ser_select_byte() and the subsequent failure.

I have no idea why this happens, but will look into it some more tonight if I get the chance.
-(e)

[sweetlilmre]

Hi,

I managed to fix/hack/workaround the issue:

GetOverlappedResult() is returning zero bytes read, however the actual character data has been read into the buffer. This would indicate a comm timeout (according to some M$ documentation).

By removing the check for the number of bytes returned from GetOverlappedResult() the mux app works as expected. I believe that this could be an issue with the USB-Serial driver I am using (a proliant chip on a generic Nokia CA-42 USB-Serial cable).

I have some other cables that I will try when I get the opportunity.

During this investigation I have managed to get the mux app compiling under VS2010, would anyone have any interest in the patches for this? If so I can clean up and submit?

Next up, SPI... that is going to be fun without a JTAG :)
-(e)

[BogdanM]

On Thu, May 5, 2011 at 10:31 AM, sweetlilmre <[hidden email]> wrote:

Hi,

I managed to fix/hack/workaround the issue:

GetOverlappedResult() is returning zero bytes read, however the actual
character data has been read into the buffer. This would indicate a comm
timeout (according to some M$ documentation).

By removing the check for the number of bytes returned from
GetOverlappedResult() the mux app works as expected. I believe that this
could be an issue with the USB-Serial driver I am using (a proliant chip on
a generic Nokia CA-42 USB-Serial cable).

Ah damn. I should've though about that. USB to serial adapters and their associated drivers are a lot of headache, I'm afraid :( I had loads of problems with them too. In any case, I'm glad it works for you. Nice debugging session, BTW :)

 

I have some other cables that I will try when I get the opportunity.

During this investigation I have managed to get the mux app compiling under
VS2010, would anyone have any interest in the patches for this? If so I can
clean up and submit?

Please submit a patch (in can be either here on the list or a pull request on github) and we'll definitely integrate it. I bet there are lots of people who'd take VS2010 over gcc.

 

Next up, SPI... that is going to be fun without a JTAG :)

Why is that? Debugging issues? For me I found out that a set of well positioned printf are a better debugging tool most of the time :)

Best,

Bogdan

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Dado Sutter]

Hi !

On Thu, May 5, 2011 at 04:31, sweetlilmre <[hidden email]> wrote:

Hi,

I managed to fix/hack/workaround the issue:

GetOverlappedResult() is returning zero bytes read, however the actual
character data has been read into the buffer. This would indicate a comm
timeout (according to some M$ documentation).

By removing the check for the number of bytes returned from
GetOverlappedResult() the mux app works as expected. I believe that this
could be an issue with the USB-Serial driver I am using (a proliant chip on
a generic Nokia CA-42 USB-Serial cable).

I have some other cables that I will try when I get the opportunity.

During this investigation I have managed to get the mux app compiling under
VS2010, would anyone have any interest in the patches for this? If so I can
clean up and submit?

Thanks for the great work Sweet we-don't-know-your-name-yet :)
Are you using git locally for your dev ?
Could you use git's Pull Request mechanism for your contributions ? This is not a requirement for now but it would be the right way to go.
 

Next up, SPI... that is going to be fun without a JTAG :)

Indeed :)
 

-(e)

Best
Dado

 

--
View this message in context: http://elua-development.2368040.n2.nabble.com/NetDuino-Serial-TX-to-board-fails-tp6323539p6333416.html

Sent from the eLua Development mailing list archive at Nabble.com.
_______________________________________________
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

[sweetlilmre]

Hi,

I will figure git out and do the patch. This will require some restructuring of the main.c code in the rfs server to pull out functionality into separate files (this works around the VS bug where you cannot compile two .c files of the same name and will be neater anyway :))

My name is Peter btw :) and the SPI stuff is going to be hard because I've never done anything like that before :)

-(e)

[Dado Sutter]

On Thu, May 5, 2011 at 07:00, sweetlilmre <[hidden email]> wrote:

Hi,

I will figure git out and do the patch.

Thanks !
We usually point to this as the best initial git learning resource: http://www-cs-students.stanford.edu/~blynn/gitmagic/
For the Pull Request concept, please check http://help.github.com/pull-requests/
 

This will require some restructuring
of the main.c code in the rfs server to pull out functionality into separate
files (this works around the VS bug where you cannot compile two .c files of
the same name and will be neater anyway :))

My name is Peter btw :)

Welcome and thanks again Peter :)
 

and the SPI stuff is going to be hard because I've
never done anything like that before :)

There are some cheap protocol sniffers/debuggers like the Bus Pirate that can help sometimes (http://dangerousprototypes.com/bus-pirate-manual/)
And as Bogdan mentioned, printf still reigns as the best debugging "tool" on the block :), as it proved to be on a very tricky debugging session on STR9 SPI yesterday :). This code will be merged to the SPI generic support on the master dev branch soon.
 

-(e)

Best
Dado


 

--
View this message in context: http://elua-development.2368040.n2.nabble.com/NetDuino-Serial-TX-to-board-fails-tp6323539p6333744.html

Sent from the eLua Development mailing list archive at Nabble.com.
_______________________________________________
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

[Mike King]

> I managed to fix/hack/workaround the issue:
>
> GetOverlappedResult() is returning zero bytes read, however the actual
> character data has been read into the buffer. This would indicate a comm
> timeout (according to some M$ documentation).
>
> By removing the check for the number of bytes returned from
> GetOverlappedResult() the mux app works as expected. I believe that this
> could be an issue with the USB-Serial driver I am using (a proliant chip on
> a generic Nokia CA-42 USB-Serial cable).

You might want to check out my patch.  Bogdan said he will revert back
to it for master.  It fixes the things listed below.

https://github.com/elua/elua/blob/1822ee1572e63ec033447d918b58466b36dba342/rfs_server_src/serial_win32.c

*The function ser_open could leak memory on failure.
*Forgot to initialize the DCBlength field of the DCB structure.
*Forgot to initialize the OVERLAPPED structure in the ser_read function.
*Initialized the OVERLAPPED structure in the ser_select_byte function
without regard to whether or not an asynchronous read operation is in
progress.
*I/O cancellation is done synchronously when it could be done asynchronously.
*The function ser_read will not update the dest buffer when the
fWaitingOnRead flag is set.  This also affects the ser_read_byte
function.
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev