Problem unsing the RS485 9600 bauds firmware version

[jagomo]

Hi all,

I was working on a driver class to use the NXTBee from dexter industries (http://dexterindustries.com/NXTBee1.html). When I was looking for a way to set up the RS485 port to work at 9600 bauds I came across this forum thread http://lejos.sourceforge.net/forum/viewtopic.php?f=7&t=2889

There, is posted a link to download a 9600 baud version of the leJOS firmware. The problem is that, when I try to flash my brick with it, LCD shows the following error:

Code: Select all

Data abort
PC      00108250
AASR    00A3E0C8
ASR     00020201
OPCODE  ???
DEBUG1  00000000
DEBUG2  00000000


And the brick does the characteristic ticking sound.

Flashing with the "original" firmawe restores everything back to normal so I guess there's a problem with the .bin file.

Any hint or advice will be very appreciated.

Thanks in advance for your time.

Javi.

[skoehler]

It's probably just a mismatch between firmware and linker. The binary format the nxj files (created by the linker) is continuously evolving. A mismatch between firmware version and the linker can cause such data aborts.

I assume the 9600 baud firmware does only work with recent snapshots of leJOS.

[gloomyandy]

Hi,
Yes as I think is explained in the thread, this version of the firmware will only work with a developer snapshot...

Andy

[jagomo]

First of all, thanks for replying so fast.

Yes, it is explained. What I didnt explained (my mistake) is that I actually have a recent developer snapshot since I wanned to test the MCL example from the Intelligence Unleashed book.

I tested the MCL example one or two weeks ago and worked, so I guess that my snapshot is pretty recent. Any more hints?

Other way I think will be to change the #define from the hs.c and rebuild the firmware myself, but i don't know how to do it. If you could point me out which steps should I take i'll be glad to do it (i'm working with windows 7 64 bit, but using everithing under 32 bit to avoid problems). EDIT: Just in case you wonder, I searched how to do it but I haven't had much luck.



Thanks again.

Javi.

[gloomyandy]

Rebuilding the firmware is not easy (you need a Linux system and a cross compiler which you have to build). It may be that you have too recent a build of the snapshot, you may want to try a version that was current at the time of the post about the test firmware, or alternately you may have too old a snapshot, so try getting the current one. You may also want to try grabbing the modified firmware again, as I have no idea why you are getting the data abort. I'm not aware of anything changing in the tool set that would cause that. Other than that you may just want to wait until i have chance to finish the work I'm currently doing to allow different baud rates to be set (along with some other changes to the RS485 code)...

Andy

[jagomo]

It may be that you have too recent a build of the snapshot, you may want to try a version that was current at the time of the post about the test firmware

Hi again,

That did the trick! I downloaded the snapshot from the sticky revision 5615 (about 3 months old) and I got the firmaware running. I tested it by sending/receiveing some chars with another NXT coded in RobotC equiped with another NXTBee module and everything is working fine.

Thank you for everything.

[skoehler]

I have question which is a bit off-topic!

Can you point me at the documentation of the protocol which is used by the NXT to communicate with the NXTBee? I want to take a look.

[jagomo]

Can you point me at the documentation of the protocol which is used by the NXT to communicate with the NXTBee?

I made a big mistake, I shouldn't have used the word "driver". As far as a I know and experienced looks like everything is already prepared. I mean, you just need to send anything you want through the RS485 port at 9600 in raw bytes and the modules detect automatically nearby nodes and send it to all of them. I didn't had to do any kind of setup or struct the data acordingly to any protocol. It look like is you job to decide how you'll filter/treat the data in every robot.

In other words I think that the actual "driver" is on the circuit board Dexter Indrustries manufacture and don't know if you can access to that.

Sorry if this could have mislead anybody.

Javi.