changing the code in the MR-C3024

[i-Bot]

Yes, I too thought they may be sneeky and use another pin, but since the code is there to jump to 0xf000 under serial control, and the reports suggest that firmware updates are done during download then I think only serial is needed. In the robobasic executable there does seem to be some dialog about down load, but I have no idea how or when it is invoked.

I have tried all sorts of response to the ">", (>, <, !, ......) but to now avail, not even an echo. The Hitec software is usually well protected, to prevent user problems, so I guess the same here.

You are correct, after a delay the main aplication code is started at location 0

Best of luck

[DanAlbert]

I am not getting a response of any type on bootup.

Is this on the serial line that hooks to RoboBasic or the ETX port?

Also I am getting a lot of activity on the I2C port on bootup. Mostly 0x53.
I assume this is the EEPROM communications. Or is it?

Dan

[DanAlbert]

Further examination of the I2C line shows most of the "device id" part of the packet is 0x53. So I assume that is the EEPROM.

In any case. why then does the I2C bus try to talk to devices 0x50, 0x51 and
0x52 on power up?

Any info from anyone would be appreciated.

Thanks,

Dan

[Bullit]

Ok, I tried sending "0xAF boot" allowing the mr-c3024 to reboot and then send the first input character and looked for response in the boot loader period, I think this is less then 1 second, to see if I got any response on any single character. I tested all values (0-255). I got no response character from any input. I can only conclude that more then one character must be sent to the bootloader to get a response.
I also tried sending the 0xAF with other commands like perhaps "0xAF load" given that the mr-c3024 app echos the b as B I tried scanning all other characters (0-255) after the 0xAF. I found that only the "b" got response so there appears to be no other hidden 0xAF command.
So miniRobot has the hex file in the rbv2.exe has that hex file changed in various releases of rbv2.exe? The hex file in the latest v2.5e is dated 10/27/2005. Thats pretty old.

[DanAlbert]

I am thinking now that there is an unlock code that will give a response from the bootloader.

Other bootloader code I have seen on the web uses a 32 bit code.

If it is only 32bits that's only about 4 billion combinations. At 1000 tries a second you could brute force it in 46 days. Or two people could brute force it in 23 days ...

That is a big assumption of course. It could be 48 bits or more.

The first question I would ask is how soon after the ">" until the bootload resets to application mode. Then if you send it one character does that delay time increase? If so, does it increase again with two characters?
If this method yields interesting data, one has to wonder how many characters can be sent until it resets.

Ah! That would be the max length of the unlock command.

[limor]

Ok.. it's 4am and i've made some progress on analyzing the protocol between the RN1 board MR-C3024.

I took two files from the RoboBasic templates, compiled them, and downloaded them into the controler. This was done while the software from www.serial-port-monitor.com was running and tracking the communications link.

The results seem pretty straightforward.

1) A prologue of about 16 fixed chars that are sent one-by-one from the PC, waiting for the RN1 to respond with the same char (except for one case).

2) Then the PC sends the short int representing the Code-lengh one byte at a time, MSB first. RN1 responds to each byte with same value.

3) then comes a magic 3F

4) now the PC sends the program in chunks of 128 bytes at a time. each chunk is preceded by a magic 21 and followed by a 2-byte checksum (havent checked the formula yet. this may be challenging). Last chunk is 0-padded to complete the 128 bytes chunk although the Code-length value only accounts for the actual code without the 0-padding.


The code sent to the RN1 is not the whole OBJ file!
The compiled obj file has 164 prologue bytes that are completely ignored by the downloader.

I've put all this evidence in word files for your viewing pleasure.
At the end of the file you can see the two screenshots of the obj file (using the freeware WinHex). one is with the preceding 164 bytes and the other without. I erased the first 164 bytes so that the sequence is alligned with the port monitor output.

http://robosavvy.com/Builders/limor/handsup_analyzed.doc
http://robosavvy.com/Builders/limor/simpledance_analyzed.doc

Next steps (help anyone?)
- decyphering the checksum
- scripting something to emulate the PC-RN1 serial protocol
- writing some hardcore C++ code for RN1, compiling it with WinAVR, sending it to RN1 for execution...

[DanAlbert]

I've been waiting for a breakthrough from someone.

Great work.

I have replaced my ATMEGA128 with a new processor and have written some code in GCC under the WINAVR.

So far my code is just some ISR timers that generate the 24 servo signals.
In addition I can receive and send USART data. (and blink the LED)
I have some untested I2C EEPROM read and write routines that I will be testing this coming week.
Most of it was working on my OLIMEX board, but is not yet working on my
MR-C3024.

I wil post the source as soon as I get it working. Unless someone else wants to codevelop this. Then I am willing to post my nonworking code too. (just don't flame me) Maybe together we can build a Robobasic replacement!

Dan

Once again Limor....great work!

[i-Bot]

There is a difference in what Limor and Dan are doing. Limor is loading code into the EEPROM on the MR-C3024. This is Robobasic Intermediate code, for interpretation by the C3024. Dan is downloading AVR binary code to the C3024 Flash. This may help to show the difference:

http://robosavvy.com/Builders/i-Bot/web ... ernals.pdf
Structure of the IM code is here:
http://robosavvy.com/Builders/i-Bot/web ... 20Code.pdf
If this is what Limor wants , then I can help. The document here:
http://robosavvy.com/Builders/i-Bot/web ... Serial.pdf
is out of date for the command EC among others. If this is what you want to do, I will update and include a better description of the other codes which may be returned to the 0x3f on errors. The checksum is a simple sum of the previous bytes.

Also note that when the port closes and reopens after the EC command, it is at 115K instead of 9600.


For Dan, just a few updates and corrections on what I have found on the flash part.

The checksum is only done on the lower 64K of flash, so that is why I get the same checksum on both my C3024 and Olimex. In fact the C3024 Robobasic application code actually checks the loader is present before it will execute any IM code. Thus you may find your Olimex will run OK all except the command interpretter when runing the Robobasic image. I can send you a patch to get around this, if you still want to use Robobasic, with your own serial loader or JTAG. This does also mean the LPM instruction is not disabled for the boot loader, but still have not been able to invoke the flash loader.

[limor]

hm..
I didn't realize that the pseudocode was residing in the EEPROM and that the actual interpreter is in the flash memory.

So my objective now should be to trace the downloading protocol of a new Flash update. Do you know how that is done?

I'm not much interested in the RoboBasic pseudocode.
This whole effort, at least for me, is in order to be able to exploit in real-time the position feedback from the servos and use these in similar way as a gyro feedback and potentially allowing some of the pathplanning calculations to be done by remote PC. ie: better real-time reaction to obstacles and uneven terrain. Otherwise RoboBasic is quite comprehensive and an excelent piece of work by minirobot.kr.

BTW: I've now seen in your documents that the Atmega128 is clocked at 7mhz and not 16mhz.. why would they do that and not get more juice out of the processor?



BTW: you mentioned in one of the documents that the pseudocode can only be viewed in the monitor. As you can see from my word files, the pseudocode is in the .OBJ files starting at byte 165. I dont know what the this 164 bytes are for.

[DanAlbert]

I am not interested in running the RoboBasic. But it is imperative that we find out how to unlock the bootloader to reload the flash. The key may be inside the RoboBasic firmware. I-bot, how far have you gotten in disassembling that monstrosity?

Removing the chip was a painstaking process that I don't recommend. As careful as I was I still broke two pads in the process.

On the other hand, we could always just build a new board from scratch.
There isn't much to it.

A schematic would be nice. Does anyone have anything besides what Hitec posted?

In addition I think it is important, no matter which way we go, to map out the EEPROM. If I'm not wrong I believe there are "Move" and "Zero" data that reside there.

[limor]

can it be that the actual minirobot interpreter that resides in the flash memory never demanded an upgrade?
they have 7 other controler boards in the MR-C3*** series which RoboBasic supports. I just can't belive that this complicated code never needed any updates.. am i missing something here or there's no menu opiton on robobasic for firmware upgrade?

[i-Bot]

Hitec are servo guys, maybe they think software updates are a sign of failure !

Still we do seem aligned on our goal to replace the frimware in the C3024 flash.

The boot loader remains elusive. The firmware for the C3024 down load is in the Robobasic program, and there are some dialogs and menu items related to it. I have tried lots of things, but have not been able to invoke the loader. The firmware has the boot command to jump to the loader, but there is no flash loader functionality in the C3024 application image.

The procesor is an ATMega128L and is clocked at 7.3728MHz. Running the processor at higher speed would not help very much under Robobasic, since most of the spare time is locked up in software loops in the firmware.

I now have the C3024 firmware fully dissasembled and it even reassembles to the same binary. I have only commented about 20%, but that is enough to determine to command interpreter and Code interpreter. To map the RAM and EEPROM (not much is used) is part done, but this only has relevance under Robobasic.

[fnastro]

Has anyone tries using the in circuit programming? I have been away from the AVR microcontroller programming world for a few years but I remember that you can program the ATMEGA "in circuit" using the SPI ports. On the MR-C3024 that is the S9(SCK), S10(MOSI), and S11(MISO) pins. I think by plugging in an AVR serial programming cable and using the winAVR software it might be able to just be Re-Programed.

[i-Bot]

Though the ICSP pins are available on ERX, ETX, and S9. the SPIEN fuse appears to be cleared to prevent access this way. Also the JTAG interface on AD4, AD5, AD6, and AD7, also appears to be disabled. These interfaces only work on a new ATMega.

I tried these on an SP Duo interface with jumper wires to the pins.

Thanks for the idea

[limor]

i-Bot: you claim that the firmware is in the robobasic program and that you have it fully disassembled.
Do you mean the actual code that interprets the Robobasic pseudocode and that resides in the (non bootloader) flash memory? how did you get this code?

Assuming you have that code, then maybe is it possible to reset the MCU using the parallel programming interface ?
This requires linking to a programmer (like the STK500) all the 8 PD and 8 PB pins and also PA0 and Xtal. See page 293 on the Atmega128 pdf).

In this case we loose the elusive boot loader but this may not be so bad IF the process of storing of the pseudocode from the PC to the EEPROM (the stuff i traced in previous post) is done by your backed up code and not by bootloader.

So in such an "unlocked" RN1 controler board there would be some publicly available boot-loader and if one wants to run a Robobasic program, one can upload first the backed up software and then the Robobasic pseudocode.