changing the code in the MR-C3024

[Bullit]

DanAlbert, I don't see why there would be a problem with the firmaware loader program. That shouldn't be violating anyones copyright. I was thinking of creating my own with this information. Perhaps I'll just wait for yours now.
I think I-bot tried to change the revision of the firmware to try to force an update but was unsuccessful.

[limor]

my idea is to reset the controller firmware version # to a lower value. this should cause a firmware reload.

If the objective is to restore the original Hitec firmware, there are at least 2 ways of doing it.

1) patch the RoboBasic code so that the statement

Code: Select all

if(controler_version <= 2.3) send_new_firmware()

is changed from 2.3 to say 2.2. this can be done with a de-compiler (haven't used this in a long time but i suppose they still exist on the web)

2) upload Dan's recorded firware to the controler.

i have also written a loader program in C++ called freeloader.
it is about 85% done..of course it may not work just to emulate the robobasic program.

why wont it work to emulate the firmware upgrade sequence?

Do you think there are any legal issues with the RoboBasic company or Hitec?

no, there are none. my RN1 is my property and i can modify it as i wish (just like my zone-free DVD player, my overclocked PC, my mod'ed PS2). Ofcourse, we should validate that there's always a way of restoring the original firmware.
Keeping the code open-source is the best way to ensure that several pairs of eyes go through the code.

i also need to change my atmega code to try and dump the bootloader.

You mentioned this before, but i don't quite follow what you mean by dump the bootloader.

[i-Bot]

Sorry this is short, but I am at the beach, and have only dial up connection.

I have successfully downloaded new code to a standard RN using the information from Dan.

Also I have the original RoboBasic code image, so I can easily restore the original code.

Download time to flash is a bit slow, since it uses 9600 bps



My RoboFlash loader is written in C#.NET, but is really only of proof of concept quality. Is there a C#.NET programmer who can help tidy it up ?

I used this also to download a dump program to dump the loader code. So we also have the source of the loader. I needed this since there is a little trick in the checksum when the block numbers are included. Previous to this only the first block would download. So my dump program was < 256 bytes

So RoboNova is OPEN in time for Christmas

[Bullit]

Awesome! I think I hear hoofsteps on the roof!
I'm not a C# expert but C++. I'm a bit of a utilitarian though. If it works.... I'd be glad to try and help.
Please share. I'm ready
I hope your beach time is going well.

[fnastro]

I am a pretty good C# and VB.net programmer. Let me know what you have and what you need.

[DanAlbert]

I don't mean to be lazy i-Bot but what is the trick to the checksum?

I assume that you mean the checksum includes the block # as well as a simple hash algorithm.

[i-Bot]

Take a look at the following code for the loader. Note how the byte pointer is XORed into the data and checksum.

http://robosavvy.com/Builders/i-Bot/cboot.asm

My AVR studio does not seem to work for ASm file on this PC, so this code is not complete or assembled, but you get the drift. This is disassembled from the board.

[Bullit]

i-bot any idea what the 2 unknowns are?

[i-Bot]

Just ignore the bit at the bottom. The first section is jumped over and contains two areas of constants. The first is the table the application uses for comparison to check the loader is present, the next part is the the name of the code and data.

The unknow is just where the disassembler tried to disassemble data. Tis is why the surrounding op code don't make sense either.

Start from after the jump.

[Bullit]

I-bot, thanks, missed that.

No wonder why its only 9600 baud, no recieve interrupt.
Very interesting stuff.

[Fritzoid]

Nice work I-bot!!!

What would be really nice is to have a downloader that runs from AVR Studio. I imagine a plug-in can be developed to treat the MR-C3024 as an emulator. Then we could download code with the Program AVR button. I've ordered the SDK to see if this feasible.

Decoding the data in your disassembly starting at word 0x09 I get the following two strings:

"Boot fer 2.3 " and "by K JSB "

So is that their typo or yours in word 0x0B?

[i-Bot]

I take full credit for the mistakes !

I managed to get the file to assemble, so have made some corrections and uploaded again.
http://robosavvy.com/Builders/i-Bot/cboot.asm

Also the lst file from the assembler
http://robosavvy.com/Builders/i-Bot/cboot.lst

The file payload25.bin is the binary image of the application code (without the loader) which is downloaded by the loader for use with RoboBasic.

http://robosavvy.com/Builders/i-Bot/payload2.5.bin

The file scode.hex is the assembler source of the application code. This will assemble to the same image as the above .bin, with the exception that unused bytes are 00 instead of FF.
http://robosavvy.com/Builders/i-Bot/scode.asm

I like the idea of a AVR studio plug in. Currently I use hex2bin and bin2hex to convert between hex and bin files. I planned to add .hex file import to my loader using the source from hex2bin (does not need segmentation)

One factor to take into account is that the current loader limits the application file size to 64768 bytes, and does not allow access to the full 128K of the AtMega128. This is not a problem for the payload, or for C files I have created, but since move data is now taking flash it may become a problem. We could rewrite the loader to be compatible with both the existing and with a more complete loader. There is plenty of space.

The files are all copyright of Hitec and MiniRobots and shared here only for the purposes of education and research.

[i-Bot]

A couple more files for today !

First for our C# wizzes, here is my loader.

http://robosavvy.com/Builders/i-Bot/RoboFlash.zip

Hey, it IS my first C#.NET program !

It needs to have better handling of exceptions and errors in the download protocol.

Also the ability to import .hex files needs to be added as it is done in hex2bin. (source available), or maybe an AVR studio plug in as suggested by Fritzoid.

Finally to satisfy my need to understand why Dan dicovered this and not me. I previoulsy faked the version 2.3, but it seems to also need the checksum correct. The attached .bin will fake both the version and the checksum. A controller info. will confirm the version and the checksum. When downloading Robobasic code, then Robobasic will upgrade this to the version 2.5 code. So nice of Hitec/MiniRobots to clean up after us hackers !

http://robosavvy.com/Builders/i-Bot/FAKE23.bin

Cheers, Dan You cracked it !

Oh well back to the beach before return to Blighty next week. RN says good to feel he sand under the LiPos. .... mmmh, those servos sound a little different !

[fnastro]

Your code is not as bad as you lead us to believe. Looks like a good job to me. I have a few layout change Ideas and I'd like to integrate the loading of a hex file. Where can I find the hex to bin code so I can pull it into the app?

[i-Bot]

Thanks,

The hex2bin source is here
http://downloads.sourceforge.net/gnuwin ... g_mirror=1

and the specification here
http://pages.interlog.com/~speff/usefulinfo/Hexfrmt.pdf

I looked a bit more into the detail of the ATMega Bootloader documentation.

The save to program memory is only possible from the loader segment, and not from the application. This implies that it would require a special loader loader to rewrite or damage the bootloader code. This means that the original state of the C3024 should always be recoverable, what ever application is loaded (good or bad). Te ability remains for the writing of a loader loader to make a new laoder to access above 0xFD00. Still best to stay small but safe for now.