Walkera RX reverse engineering

Hello,

I did very preliminary analysis of newer Walkera RX schematics.


Receiver RX2636H-D, as found on new V120D02S.
MCU: XMEGA32A4
Accelerometer MMA8452Q, I2C, at SDA/PC0 and SCL/PC1 (pins 10, 11)
Gyro ITG3205, I2C, at SDA/PE0 and SCL/PE1 (pins 28, 29)
Servos connected to:
RUDD = PE2/OC0C (pin 32)
ELEV = PD3/OC0D/TXD0 (pin 23)
AILE = PD2/OC0C/RXD0 (pin 22)
PIT = PD1/OC0B (pin 21)
THRO = PC2/OC0C (pin 12)
AUX input connected to PA5/ADC5 (pin 1)
Three potentiometers are just providing constant voltages to ADCs:
RUDD EXT = ADC11/PB3 (pin 7)
ELEV/AILE EXT = ADC10/PB2 (pin 6)
ELEV/AILE G = ADC9/PB1 (pin 5)
Dual LED is at PD4 (pin 24), red, and PD3 (pin 23), green. Active low. Green seems to be not used in stock firmware.
Dual switch is at PD5 (pin 25), unused, and PD6 (pin 26), ADJ-WK.
An unidentified unsoldered 4-pin component goes to pin 33 (PE3). Another two soldering points go to ground, the fourth pin is nc. Looks like pushbutton.
Pins 13?,14-16 (SPI) go to CYRF6936.
Telemetry not traced yet, sorry.

Receiver RX2632V-D, as found on MiniCP:
CPU: the same
Gyro: the same, but wired in place of accelerometer (10, 11)
Accelerometer: none, but empty pads for MMA8452Q. Wired to 28, 29, respectively.
Servos: pins 21-23 (same), not sure about order.
Motors: npn+pnp driver for each motor and a dual FET, PWM comes from pins 12 and 32 (like THRO and RUDD outputs above)
LEDs and switches: no switch soldered, but there's space for one. LEDs and switch swapped, PD3, PD4 (23, 24) go to switch, PD5, PD6 (25, 26) to the LED. Led is dual too, green unused, red at PD6.
Potentiometer at ADC11/PB3 (7), place for another one wired to pin 6 (ADC10/PB2)
Telemetry: motor temperature input at 43 (PA3/ADC3), similar unsoldered 2-pin input at 44 (PA4/ADC4), battery voltage at PA5/ADC5 (pin 1).
CYRF connected in the same way.

Coming soon: QR Ladybird receiver.

All receivers have power supply made from LTIZ (or similar, "PH01" on my V120, completely unreadable on MiniCP). The V120D02S has 15uH coil. They say there's 10uH coil on MiniCP (I crashed it, sorry, replaced with 10uH and it works fine). An unidentified SOT23-5 with text "L04A" (MiniCP) or "JJ-TO8" (V120D02S) then, probably an LDO. Power to the MCU comes from this chip.

Both receivers have test points at PDI_DATA and PDI_CLK.

I also tried to analyze the firmware as downloaded from Walkera. No success yet but they're definitely XORed by a random 16-byte code. First 512 (?) bytes are very similar (FFs? 00s? EEPROM?) and may be used to guess the XOR code. After unXORing, all files have many bytes matching between them. But not AVR code yet...

I think about writing a custom firmware from scratch.

I had the idea to use a 3-axis stabilized walkera rx as a complete quadcopter controller, including the RX part.

Here's some hi-res images:

wuselfuzz.de/crapcopter/rx2433.png

wuselfuzz.de/crapcopter/rx2435_gyro_bottom.jpg
wuselfuzz.de/crapcopter/rx2435_gyro_top.jpg
wuselfuzz.de/crapcopter/rx2435_programming_wires.jpg (this is what I'm also currently using to dump SPI data)
wuselfuzz.de/crapcopter/rx2435_top.jpg
wuselfuzz.de/crapcopter/rx2435pins.txt

The gyros are Invensense IDG-650 and ISZ-650, connected to ADC inputs.

uC on the older RXes is an atmega48168. Interestingly, it had the whole ISP interface disabled, the controller didn't even react on a programmer attached to the ISP pins. The connections were correct, though, dumping SPI works just fine. You can do that by using a parallel programmer. Which is probably what happens in mass productions by using some spring contact header on the whole chip. I'd expect the code protection fuse set, too.

Since my UFLY did a horrible chicken dance recently, I might even take up this project again, I have another basically new RX2435 and might replace the uC on that with a non-locked atmega328.

PhracturedBlue wrote: Very cool information. I'm not very familiar with AVR programming. Is it possible to download the firmware from the device itself?

Not tried it yet but this is very unlikely. AVR has a read protection fuse. I don't believe this fuse is left unset.

PhracturedBlue wrote: Are you sure it is purely an XOR?

No.

But I'm sure that every *.bin file has many repeated bytes at its beginning. It is mostly periodic with 16-byte period. Assuming that the file starts with some 512-byte sparse block (most bytes either 00 or FF, only some bytes differ) I got an 16-bit XOR key. This key is different for all RXs. After XORing *.bin to this key I got a byte sequence that is very similar for all RXs. It starts around byte 512.

PhracturedBlue wrote: Also does the AVR have an interrupt jump table? If you have known or semi-known data it can make finding the codes easier.

It has but it is just table of 16-bit addresses at the very beginning. No asm commands here, so looks more like completely unknown data.

The preamble of AVR code should probably have CLI command or something like it. And there are register addresses of SPI and I2C that should be used everywhere.

PhracturedBlue wrote: Do you have a specific goal for writing a custom Rx firmware? I don't see as much benefit as for the Tx, but maybe I'm being short-sighted.

My primary goal is to be able to modify hardware.

Every Walkera RX has some unpopulated parts on the board or unused connectors. I want to use them to add extra channels for controlling navigation lights or something. Also MiniCP has no accelerometer but has place for one, what if I install one?

Also it is theoretically possible to make a multi-protocol receiver or to extend existing DEVO protocol.

wuselfuzz wrote: I had the idea to use a 3-axis stabilized walkera rx as a complete quadcopter controller, including the RX part.

Here's some hi-res images:

Thanks!

No surprise that SPI programming is disabled. They probably use a gang programmer in mass production.

ATmega**8 should have more compicated firmware since it has less PWM outputs. More software code and more freedon.

All XMEGA receivers should be alike. I heard Blade has XMEGA too, is it right? I do not own any Blade. If so, there are chances to make "all-in-one" firmware for both newer Walkera and Blade.

FDR wrote: Ladybird has the XMEGA32A4 too...

My Ladybird is on the way. I'll draw its schematics as soon as I receive the shipment.

FDR wrote: I was wondering if these MCUs have enough power and outputs to handle brushless motors directly (3 outputs each) which would only required an additional power mosfet to drive each coil...

Most likely yes. XMEGA has sophisticated timer and event handling circuit that allows for motor controlling without CPU usage at all.

In fact, all the servos in Walkera stock receivers are connected to PWM outputs. So in C code it takes just
SOME_PWM_REG = x;
to move a servo or change brushed motor RPM.

AFAIK, SuperFP has 5-wire servo connectors and the MCU handles servo feedback as well.

If they're using two-stage obfuscation, the code for the 2nd stage seems to be the same for all models. At least after XOR all the files look very similar:

MiniCP:
97 51 A4 0E A1 AD A7 0E E3 F0 B5 2B DE 1B B4 2B ... 04 60 92 C0 ...

V120D02s:
97 51 A4 0E A1 AD A7 0E E3 F0 B5 2B DE 1B B4 2B ... FB 9F 6D 3F ...

And there are parts like insertions - the same byte sequences are shifted.

I think the only advantage of decrypting this is the ability to encrypt our own firmware for the stock bootloader. And the ability to flash the stock firmware back after playing with custom firmware.

have one more things. i take compiled code for xmega32a4 and New120D02S_V1.bin
first bytes is a JMP interrupt table. i compare both and generate XOR sequiens. it have strange error, after decoding JMP table look good, but code messy. need more calculating. files:
add: true XOR key for new v120d02s heli (RX-2636H-D)
add2: link to a russian forum with details www.rc42.ru/forum/4-720-20688-16-1359720834
sorry, russian letters only.

Gall wrote:
AUX input connected to PA5/ADC5 (pin 1)

hi all, i googled to the best of my ability and could not find what the 5th AUX port is for. i've found only 2 mentions of it, here being 1. i'm not an engineer, obviously, i'd be very grateful if one of u guys would help me out.

Gall wrote: If they're using two-stage obfuscation, the code for the 2nd stage seems to be the same for all models. At least after XOR all the files look very similar:

MiniCP:
97 51 A4 0E A1 AD A7 0E E3 F0 B5 2B DE 1B B4 2B ... 04 60 92 C0 ...

V120D02s:
97 51 A4 0E A1 AD A7 0E E3 F0 B5 2B DE 1B B4 2B ... FB 9F 6D 3F ...

And there are parts like insertions - the same byte sequences are shifted.

I think the only advantage of decrypting this is the ability to encrypt our own firmware for the stock bootloader. And the ability to flash the stock firmware back after playing with custom firmware.

Gall, were you thinking to create a new bootloader or use the stock one? Are you still looking at this project? I'd like to see added functionality on the 2703h-d as well and I'm very interested to see how you guys make out on this.

Cheers

Yes. Unfortunately I'm very short of time. But at least I don't like "magic numbers" in the code, so everything that is not documented should be rewritten...

As it seems semi-relevant to this thread, just wondering if anyone knows if channel 5 is used/available in any way on the Walkera FBL RXs? ie. in Hexperience's FBL Setup guide it says that channel 5 is unused, and that the gyro setting is on channel 7; does that mean it's essentially just a 6ch receiver, or is it really 7ch (or more) but with a blank channel for some reason?
I haven't found any reference anywhere online as to what is happening with this "missing" channel. Would be interesting if there's a pinout just sitting there waiting to be tapped.

Actually, I think of one interesting point in writing the RX firmware. That is to build a RX with telemetry function together in a small form factor. Just only I/O codes needed, no need the codes for balancing a helicopter. I think this should not be difficult anyway.

richardclli wrote: Actually, I think of one interesting point in writing the RX firmware. That is to build a RX with telemetry function together in a small form factor. Just only I/O codes needed, no need the codes for balancing a helicopter. I think this should not be difficult anyway.

Yes, that would be a great thing to do. I still hope Walkera comes out with a third generation RX with at least 1 analog telemetry line. All I really need on 90% of my planes and helis is the flight pack voltage.

As far as the codes for balancing the heli, what I'm looking for is simply the ability to alter the values of the existing firmware. For example the RX2703h-d is a very nice 6 axis gyro/rx but if you want to change something such as the tail stop speed you can't. Total pie in the sky wishes I know, but after using the tarot zyx and the pc software I dream of the same thing for the Walkera RX/Gyros.

I know that simply hacking the existing firmware is not exactly the mission statement of this web site... But if anyone has any ideas for custom firmware on the RX, it's this group of guys...

"... An unidentified SOT23-5 with text "L04A" (MiniCP) or "JJ-TO8" (V120D02S) then, probably an LDO. Power to the MCU comes from this chip. ..."
www.ti.com/lit/ds/symlink/lp2981-n.pdf <-- L04A
My broken (V120D02S) receiver has a "DX=712". Likely a 100mA 3.3V LDO. Pin-out is the same as LP2981-n, and many other fixed output LDOs. Current rating is related to heat generation. As these regs "burn up" excess voltage, heat-sinking is closely related to current capacity.
Temp rating is important for these guys as they may run hot with high input voltage.

Hi, I have a problem with an RX2636H-D receiver (Walkera V120D02S). I am very fond of this helicopter and have been flying there for years. Unfortunately, suddenly it does not bind to TX. The LED on the RX2636h-d flashes slowly as when the ID is cleared. It stays like this and the servo elevator seem crazy. they move without reason. I have not had any crashes. the defect began little by little. first the elevator servo went to the end of the stroke. then sometimes the bind with the TX was canceled, but after removing the battery and connecting it again, everything seemed to work. now it is no longer possible to establish a link with the TX. I would like to understand if the problem is to be found in some components such as a capacitor, or the processor xmega32a4 has been damage. I tried to put the firmware back, but it gives me a connection error.
I'm good at welding in SMD, but I do not understand much about software. I'm almost sure that the PD3 port (pin23) is damaged.

For example, could I buy an atmel xmega32a4 and replace it with the faulty one? and then flash the firmware? I suppose the bootloader is also necessary? Where can I find?
I'm sure you can help me.