On Linux, linxt will upload any file except a .rxe [SOLVED]

[seantellis]

Hi folks. I'm a Linux user (Kubuntu 10.04 LTS) who has just got a NXT (firmware v1.28) and I'm trying to get going.

I have got as far as compiling a simple sample program using nbc, and I am using linxt to communicate with the brick. Connection establishes successfully, and I have verified that I can read battery voltage, download files from the brick, and upload them to the brick. However, when I try to upload a .rxe file, it fails with error 0x92 ("Illegal filename").

If I try to upload a file that already exists, I get error 0x8F ("File exists"), as expected.

At first I thought this might be a verification error, as I was compiling a simple example using nxc, but I've tried it with the DemoV2.rxe file that came with the brick, and it still refuses.

If I rename DemoV2.rxe to DemoV2.rso, then it's quite happy to accept it, and I can see it in the list of files on the brick display, so I'm fairly confident that the data is making it across.

I have spent some considerable time trawling around the internet, and have delved as far as downloading the communication protocol documentation. I have also extended linxt to add a "remove file" command, which also appears to work OK.

Finally, I tried hacking linxt's upload function to use the "Open Write" command code instead of "Open Write Data", just to see if there was a difference in permission between the two. This will happily open a file handle for DemoV2.rso, but not for DemoV2.rxe (this time, it always reports that the file exists, even though it doesn't).

I have now exhausted my immediate options. Any help would be greatly appreciated. (I'm hoping that someone will tell me that there's a "protect .rxe files" switch under a little panel somewhere...)

Sean.

[seantellis]

More information - I have now installed the "t2n" utility and it is exhibiting exactly the same behaviour.

This suggests to me that there's something odd about the brick itself. The USB library doesn't think about the information it is transferring, so it's extremely unlikely to be that, and the only other item common to both t2n and linxt is the brick. I will continue to experiment and report back.

Any suggestions gratefully accepted. I will continue to explore.

[seantellis]

...and I have reset the brick, by the way, and I have also unplugged all other connections except the USB, just in case.

[hassenplug]

I THINK rxe files need to be written in continuous blocks.

Try clearing all the other files off your NXT, so you can be sure there's enough continuous room.

Second, I think the two write functions you're playing with allow continuous vs non-continuous data writes. I don't recall which is which.

Hopefully, that will help get you going the right direction. Maybe John will jump in with the correct details.

Steve

[seantellis]

Steve, thanks for the reply.

I have already hacked linxt to try both "normal" write commands (0x81 and 0x8B) - and both fail at the "open" stage. One with "file exists" and one with "illegal filename".

But I haven't tried the linear write command.

What really puzzles me is that, as far as I can tell, no other user of linxt (or t2n) appears to have reported this problem. Many of the "NXT for Linux" websites include uploading a .rxe file using linxt as the final step in the compile-and-test process. If it was an intrinsic property of the commands, I would expect it to fail consistently on many bricks.

This is a new brick, from a brand new sealed box, so it shouldn't be in a funny state. The demo software seems to work OK (or it did before I deleted it).

However, I will have a look around and see if I can discover whether we need to use the "write linear" command, and what the possibilities could be.

(And I'm just betting that it will be a silly configuration error in the end - but until then it's a little bit frustrating.)

[seantellis]

Harrumble! I'm in business! Thanks for the tip, Steve.

In linxt, changing the command for upload from Open Write Data (0x8B) to Open Write (0x81) does the trick. I must have screwed up before - probably not closing the file properly so it was present but not visible.

Just for information, I downloaded the firmware source from Lego, and it's very clear from the command interpreter what's going on.

If you try to open a "system" file (.rxe, .sys or .rtm) using the Open Write Data command, it immediately rejects the request with "illegal filename". (So, how come this is exactly what linxt does? Perhaps previous protocol versions were more forgiving.)

If you try to open a system file using a "plain" Open Write command, system files are in fact opened as linear files instead.

Right - now to the serious business of actually playing with it!

[afanofosc]

If you are willing, I would be interested to work with you to try out my new libnxtspirit.so shared library which supports Bluetooth and USB connections and exposes a high level set of functions that BricxCC and all my NXT tools use to communicate with an NXT. Also, if you are interested, you could try integrating with my new libfantom.so shared library which implements the exact set of functions that LEGO/NI provide in the fantom.dll for Mac OSX and Windows.

I have written a Pascal application (spirittest) that uses libnxtspirit.so and it works exactly the same as (or 99.9% the same as) my nexttool utility which compiles the communication layer code directly into the app instead of linking to libnxtspirit.so. I have not yet tried writing a C/C++ application that links to libnxtspirit.so so if you would be willing to try doing that I'd love to work with you.

The Pascal-based interface unit that exposes the libnxtspirit.so functions to an external application is here:

https://bricxcc.svn.sourceforge.net/svn ... spirit.pas

An example of how to transfer a file to the NXT is shown below:

Code: Select all

unsigned long handle = FantomSpiritCreate(); // 32-bit handle
// Then open the connection:
FantomSpirit.SetPort(handle, "usb"); // any brick resource string could be used here
if (FantomSpiritOpen(handle))
{
  // Then tell it to download the file to the NXT:
  FantomSpiritNXTDownloadFile(handle, "filename.rxe", NameToNXTFileType("filename.rxe"));
}
//Then destroy the handle:
FantomSpiritDestroy(handle);

A pascal program that demonstrates calling many of the libnxtspirit.so functions is here:

https://bricxcc.svn.sourceforge.net/svn ... ittest.dpr

John Hansen

[seantellis]

John,

Thanks for the opportunity. However, I have so far done nothing with my NXT other than run the included demo. Perhaps in a while when I find my feet, and start doing something more ambitious.

[afanofosc]

I would highly recommend using nexttool rather than linxt or other tool if you are going to be using nbc on Linux. Also, there is no need to use an external tool to download the RXE to your NXT if you are using nbc on Linux since it includes built-in download support.

nbc -d demov2.nxc

This will compile the code and download the resulting binary to the NXT via USB without ever saving the output to a file. If you are using a version of nbc that does not include download support then you are using a version that is extremely old. You would be best served by using the very latest version of nbc.

John Hansen

[seantellis]

*** Bangs head on desk ***

Thanks!