changing the code in the MR-C3024

[i-Bot]

The C3024 firmware is a payload in the standard RoboBasic executable, hence why we know that it can be updated.

I have been rather busy, but have decoded more of the firmware and so now understand the servo control and gyro code. Unlike the code above, they use a scheme where the timer interrupts every 4 milliSec, and the servo/gyro are processed in 4 phases using software delay to determine the timing. Phases 1 to 3 servo, phase 4 is gyro.

I repeat there is no key to the boot loader in the application code.

Does anyone know more about the site:
robonova.wetpaint.com

?
they have some information I was missing, plus I have information they don't.

Plus I don't have Japanese except babelfish !

[limor]

The guy behind the site seems like he has done some serious digging into the MR-C3024. I posted a response note on his blog. asking him if he has an answer to firmware upgrade. hopefully we'll hear from him.

i-Bot, why would they have put the whole firmware into the RoboBasic exe file if not to download it into the RN1?

Can it be that if you run a new RoboBasic and in talking to the RN1 it finds out the firmware version is lower than what he has, then it will quietly update the firmware?

[DanAlbert]

One weird thing is that there is no good reason to lock us out if the assembly code is in plain site.

BTW, I had a set back with the I2C. It turned out to be a short on the clock with one of the servo out pins. I need to get a better smd soldering iron.

I pulled the chip and reseated it. All is well and I can now talk to the EEPROM.

Of course I'm not sure what I'm going to do with all that EEPROM, but it's nice to know its there!

[i-Bot]

It has been a while since we had any posts on this topic, so I thought I would give an update, and pause for a sanity check from Dan and others of what I have done to date.

We did see a new version of Robobasic, but the C3024 payload was the the same as before dated Oct 2005. !!Happy Birthday !!

I have entered the schematic, board and library into Eagle. I have not routed, and some of the library is still not quite right. I did not find the jack socket they use anywhere, and although I have data on the buzzer and the switch, I have found no supplier. I decided to do some more work on the firmware before making new boards, which was just as well, since things I found there have changed my board design. Specifically, I will drop the buzzer, the spare LED driver, and the RS232 driver. Since I use JTAG, I will need this, but consequently loose AD4 to AD7 and 2 gyros, Also I lose the Remote control unless I move to another pin. Also the serial port needs flow control if I use higher speeds and more than one character at a time, this is due to the large amount of hime the code spends in the interrupt routines. So I plan to use an FDTI 232R and go USB.

For the firmware I took the assembler routines from the C3024 code and made c functions of them. I did not bother with the music, LCD, EEPROM, Port I/0, and also I do not support AI motors. I added a few the resulting in the following:
extern uint8_t remocon(void); // AS C3024 REMOCON(), except only (1)
extern void c3024_init(void); // initialises the C3024
extern uint8_t rcin(uint8_t); // as C3024 RCIN()
extern uint16_t sonar(uint8_t); // as C3024 SONAR()
extern void pwm(uint8_t, uint8_t); // as C3024 PWM()
extern void fpwm(uint8_t, uint8_t, uint8_t); // as C3024 FPWM()
extern void erx_etx_open(uint8_t); // Open ERX and ETX at specified BAUD rate
extern void erx_etx_close(void); // Close ERX and ETX
extern uint8_t erx_char(void); // get char from ERX
extern void etx_char(uint8_t); // send char to ETX
extern uint8_t etx_ready(void); // ETX char sent ?
extern uint8_t erx_ready(void); // ERX char received ?
extern void srx_stx_open(uint8_t); // open SRX and STX at specified BAUD rate (this is PC port)
extern void srx_stx_close(void); // close SRX and STX
extern uint8_t srx_char(void); // get char from SRX
extern void stx_char(uint8_t); // send char to STX
extern uint8_t stx_ready(void); // STX char sent
extern uint8_t srx_ready(void); // SRX char received
extern void motion_init(void); // initialise the servo motion
extern uint8_t motorin(uint8_t); // as C3024 MOTORIN()
extern void dir(uint8_t, uint8_t, uint8_t); // as C3024 DIR()
extern void getmotorset(uint8_t, uint8_t, uint8_t *); // as C3024 GETMOTORSET()
extern void motor(uint8_t); // as C3024 MOTOR()
extern void motor_off(uint8_t); // as C3024 MOTOROFF()
extern void zero(uint8_t, uint8_t, uint8_t *) // as C3024 ZERO();
extern void ptp(uint8_t); // AS C3024 PTP SETon and SETOFF
extern void servo_ctl(uint8_t); // used to set PTP ALL ON
extern void speed(uint8_t); // as C3024 SPEED()
extern void servo(uint8_t, uint8_t); // as C3024 SERVO()
extern uint8_t move(uint8_t, uint8_t, uint8_t *); // as C3024 MOVE()
extern void delay_set(uint16_t); // sets the delay timer timer is interrupt based in mSec
extern void delay_busy(uint8_t); // check for end of delay
extern void delay_wait(void); // wait for end of delay
extern void gyro_set(uint8_t, uint8_t, uint8_t *); // as C3024 GYROSET()
extern void gyro_dir(uint8_t, uint8_t, uint8_t *); // as C3024 GYRODIR()
extern void gyro_sense(uint8_t, uint8_t, uint8_t *); // as C3024 GYROSENSE()

These together take about 10% of the code space and 12% of the data space available on the ATMega128. However they also take 50% of the processor cycles due to the way the servos are handled. A faster processor would still loose 50%, but there would be more cycles. I did not change processor, since there is a lot of time critical code in the C3024.

The above approach means I can almost replace Robobasic with function by function C equivalents.

For testing status, I have tested the non interrupt code including motorin, pwm, sonar, and Remocon. Also tested the initialisation and seting routines for the motion. Next step is the interrupt part, which is the motion, delays, and RCIN.

[DanAlbert]

OK who wants to play???


I captured the firmware update with my logic analyzer.
I have no idea what is going on yet.

Here is what I see:

RN PC

......F0
F0
......00
02
......02
02
......02
03
......03
40
......40
BE
......BE
05
......F7
F7
......F2
F2
......04
04
......00
0D
......F7
F7
......F3
F3
......04
04
......00
C9

15 mSec goes by
......AF
AE
......62
42
......6F
4F
......6F
4F
......74
54

400 mSecs goes by (possibly a restart)


3E
......3C
......F0
......A5
......5A
......0F
......80
......53
5A
70
66
54
21

......00
......00

......7F
......C0
......18
......95
......43
......C0
......18
......95
......41
......C0
......18
......95
......3F
......C0
......18
......95
......3D
......C0
and more and more....

[i-Bot]

Hey Dan, nice work, where did you find a version 2.3 board ?

I can confirm this is a valid bootloader sequence.

The initial dialog is a normal get controller info string

Controller reads the C3024 board information
Controller ID 2
Version 2.3
Memories, variables and stacks as usual

The PC then reads two locations in C3024 RAM (4F2, 4F3) where the checksum of the bottom 64K of program is located. this is 0x0DC9

The PC decided to download new firmware.

The command AF BOOT forces the application code to jump to the bootloader at 0xf000. This is also where the C3024 goes on power up reset.

The 0x3e char is always sent on power up and is the prompt from the loader.

The next sequence is the KEY. 0x3C, 0xF0, 0xA5, 0x5A, 0x0F, 0x80, 0x53
This may also have a command appended.

The PC responds.

I assume the 00 is the start address, since the following bytes from 7F, C0 are the actual application code starting at location 0.

Is the following data in blocks ? If so can we see the end of block, and end of file sequence ? The total length should be about 0x6200 words.

Nice catch !

lpm is not disabled for the bootloader, so is should be easy to read the full bootloader protocol from an application program.

Let me know if you need help

[Bullit]

Wow! This is huge! Red letter day for RN-1!
Nice work Dan!
I'll continue to look forward to your updates.
If there is anything I can to do to help!

[limor]

Hi Dan,
Great work!
Did you just connect the PC to a RN1 that has 2.3 firmware?
or did you emulate the response of the C3024 board?

[DanAlbert]

The data blocks are 257 bytes each.
I believe that the 257th byte is a CRC.
I have not yet been able to figure out the CRC algorithm.
Since RoboBasic was so trashy I though that the programmer might just have used some simple hash like adding up all the bytes and ANDing off the last 8 bits with 0xff.
So I added up the data and got 0x4F8A
(The number at the end of each line is the sum of that line not actual data)
However the 257th byte was 0xAA (close but no banana!)

Here is data from the first block. (block 0)
7F C0 18 95 43 C0 18 95 41 C0 18 95 3F C0 18 95 - 6f6
3D C0 18 95 3B C0 18 95 39 C0 18 95 37 C0 18 95 - 69c
35 C0 18 95 33 C0 18 95 31 C0 18 95 2F C0 18 95 - 67c
2D C0 18 95 2B C0 18 95 A5 C0 18 95 27 C0 18 95 - 6d8
9F C0 18 95 23 C0 18 95 4D C1 18 95 1F C0 18 95 - 6e3
1D C0 18 95 1B C0 18 95 19 C0 18 95 17 C0 18 95 - 61c
15 C0 18 95 13 C0 18 95 11 C0 18 95 0F C0 18 95 - 5fc
0D C0 18 95 0B C0 18 95 09 C0 18 95 07 C0 18 95 - 5dc
05 C0 18 95 03 C0 18 95 01 C0 18 95 18 95 2E 00 - 52b
3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 00 - 393
20 4D 52 33 30 32 34 20 20 20 20 20 20 20 20 00 - 288
20 20 20 20 20 6D 69 6E 69 52 4F 42 4F 54 20 00 - 3f3
20 62 79 20 4B 4A 53 20 4A 53 42 20 20 20 20 00 - 362
20 76 65 72 20 32 2E 35 30 20 20 20 20 20 20 00 - 312
20 32 30 30 35 2E 31 30 2E 20 32 37 20 20 20 00 - 28d
3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 3D 00 - 393

In addition to the data, each block is preceded by a block number in Little Endian format. so block one sends 01 00.

After each block the RN sends back a 0x21.

Most likely an acknowledgment that the block is valid and written.

So until we figure out the CRC part of the protocol we probably can not reprogram the ATmega.

However, we could be real sneaky. Just write a small program in assembly code that could sit in the first block of memory and dump the bootloader.

Of course we need a windows program to send/receive the serial data to the RN. I can whip up one of those pretty fast.

Then we could just keep writing the same block of our special code with all 256 possible CRC codes. As soon as we get an 0x21 we are there!

It all sounds so simple doesn't it? 8>)

Dan

[i-Bot]

I make line 13 to be 382 not 362.

You may be closer than you think !

[i-Bot]

Btw. this looks very similar to megaload, which I have been using as a replacement. Just a few added "security" features from hohohotec!

[DanAlbert]

Thanks i-Bot I thought I checked that twice.

I need glasses.

I'll get started on a serial loader program.

Got a hex or binary file to try?

Dan

[Bullit]

Dan Albert,
I checked the checksum of the block posted, the first block of the firmware embedded into rb2.5.


I've checked this a few times and don't have the entire recording. If you can forward me the entire recording I can check more packets but I get a 8bit checksum of 0xAA for this first one.

[limor]

hi, any progress on decoding the checksum formula?

can the RN1 board be formally declared "firmware upgradeable"?

[DanAlbert]

both i-Bot and Bullit pointed out that i need glasses.
i had the algorithm right but missed an 0x20 in my calculations.

i spent the last two weeks pushing out a firmware rev for a client so not much else has been done.

i will be getting back to it this week.

my idea is to reset the controller firmware version # to a lower value.
this should cause a firmware reload.
any clue where it is located?

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.
When working, it would be nice to post it onto the web.
Do you think there are any legal issues with the RoboBasic company or Hitec?
i also need to change my atmega code to try and dump the bootloader.

Dan