I have a de-canned Telemetry upgrade module on my desk, I will get some pics later. I have the main board and LCD board pics now. Will put them on my site.

Edit: RF Amp is a T212

Edit2: HW Pr0n

Here's a list of the physical connections to the STM32F103VCT6.
I think it is about done except for the connections to the LCD Module

Thanks to rcH4x0r for a lot of this!

MISC
BOOT0: CON2
NRST: Debugger (NRESET)

GPIOA
1: Buzzer
2: output to 0 to shut off Tx???
3: power-switch in 'off' position (goes high on 'off')
5(SPI1_SCK): SPI Flash, TSC2008
6(SPI1_MISO): SPI Flash, TSC2008
7(SPI1_MOSI): SPI Flash, TSC2008
9(USART1_TX): Trainer Rx?
10(USART1_RX): Trainer Tx?
11(USBDM): USB+
12(USBDP): USB-
13(SWDIO): Debugger SWDIO (TMS)
14(SWCLK): Debugger SWCLK (TCK)

GPIOB
0: TSC2008  Chip-Enable
1: LCD Module (Backlight control?)
2(BOOT1): SPI Flash Chip-Enable
5: TSC2008 Pin 15 Pen/Irq
6: Button Matrix Col 1
7: Button Matrix Col 2
8: Button Matrix Col 3
9: Button Matrix Col 4
10: USB
11: TxModule pin 10 - CYRF6936 Reset
12 (SPI2_NSS?): TxModule pin 1
13 (SPI2_SCK?): TxModule pin 3
14 (SPI2_MISO?): TxModule pin 9
15 (SPI2_MOSI?): TxModule pin 7
GPIOC:
0 (ADC_IN_10): Elevator Stick
1 (ADC_IN_11): Rudder Stick
2 (ADC_IN_12): Aileron Stick
3 (ADC_IN_13): Throttle Stick
6: Gear Switch
7: Elevator D/R Switch
8: Rudder D/R Switch
9: FMode 0 Switch
10: FMode 2 Switch
11: Aileron D/R Switch
12: Mix 0 Switch
13: Mix 2 Switch
GPIOD:
0-1: LCD Module
4-5: LCD Module
7-11: LCD Module
14-15: LCD Module

GPIOE:
2: Button Matrix Row 1
3: Button Matrix Row 2
4: Button Matrix Row 3
5: Button Matrix Row 4
6: Button Matrix Row 5
7-15: LCD Module
GPIOF

Button Matrix

     B.6         B.7        B.8           B.9
E.2  L-          DN-        NC            Elevator Trim Down
E.3  R+          UP+        Top Right TD  Throttle Trim Up
E.4  Ent         Ext        Top Right TU  Elevator Trim Up
E.5  Aileron TR  Rudder TL  Top Left TU   NC                
E.6  Aileron TL  Rudder TR  Top Left TD   Throttle Trim Down
TL:  Trim Left   TR: Trim Right
TU:  Trim Up     TD: Trim down

Yeah, they are tied together. Weird eh?

<guess>It may be a form of multiplexing, if the "other side" of the switch is controlled by a GPIO pin then the buttons would form a kind of matrix. Detecting which button is pressed requires the MCU to set an output and then read an input, depending on the output that was set you can tell which button is which</guess>

Edit: looks like the digital trims may be doing the same thing - vertical mirror symmetry?

Originally Posted by PhracturedBlue

I'm starting to make a list of the physical connections to the STM32F103VCT6.
I haven't made much progress yet, but I'll try to keep the list updated:

GPIOA
3: power-switch in 'off' position
GPIOB
GPIOC
GPIOC
GPIOD
GPIOE:
2: DN- button,  L- Button
3: UP+ button, R+ Button
4: EXT button, ENT Button

Something i don't understand: the left and right banks of buttons appear to be tied together (both visually from rcH4x0r's pics, and by checking with my voltmeter), but they behave differently.

They might be connected in an array, resulting in less IO ports used...

Edit: Ooops, I was late again!
You guys are lightening fast...

Originally Posted by FDR_

They might be connected in an array, resulting in less IO ports used...

Edit: Ooops, I was late again!
You guys are lightening fast...

The weird thing is that on bootup, the bootloader checks GPIOE.4 to determine whether to boot or enter programming mode. this pin goes high if either button is pressed, and I didn't see any other checks being done, yet the MCU won't enter programming mode. I must have missed something.

Originally Posted by rcH4x0r

...
Edit: RF Amp is a T212
...

Does it look like this:
rc.fdr.hu/RDAT212.pdf

Originally Posted by PhracturedBlue

The weird thing is that on bootup, the bootloader checks GPIOE.4 to determine whether to boot or enter programming mode. this pin goes high if either button is pressed, and I didn't see any other checks being done, yet the MCU won't enter programming mode. I must have missed something.

As rcH4x0r wrote it an output and an input that uniquely addresses each button.
So it is the GPIOE.4 to watch, but the MCU should set an other output to H state before...

Y, could well be that chip. I will post a pic of the RF module tomorrow

Originally Posted by FDR_

Does it look like this:
rc.fdr.hu/RDAT212.pdf

That looks like it could match the pic on 9xforums. If so, it has about a 22dBm max power which would be around 160mW. However, the gain looks likely to be fixed on the module, so we need to know which power-levels of the CYRF6936 Walkera is using so we can estimate the gain. If they've tuned the max-out of the CYRF (2.5mW) to be 100mW output, then you probably can't go any higher without modifying the module itself.

IF that is the amp then 100mw looks about the max...

Looking at the code, it looks like they probably used the ST Standard Peripheral Library or something similar. if we knew which compiler they used, we could probably generate fingerprints of the library and quickly identify the library functions with IDA.
I found the SPI reading/writing functions I think, and see where they call them for SPI2 (which should be the Tx module).

using the 8-FWDT-0.7A:
sub_80280c0: Write 1 byte of R0 to SPI2, Return Rx byte
sub_802806c: Initialize SPI2???

Originally Posted by PhracturedBlue

Looking at the code, it looks like they probably used the ST Standard Peripheral Library or something similar. if we knew which compiler they used, we could probably generate fingerprints of the library and quickly identify the library functions with IDA.
I found the SPI reading/writing functions I think, and see where they call them for SPI2 (which should be the Tx module).

using the 8-FWDT-0.7A:
sub_80280c0: Write 1 byte of R0 to SPI2, Return Rx byte
sub_802806c: Initialize SPI2???

Are you saying a C language decompile is possible ?

Originally Posted by NorCalMatCat

Are you saying a C language decompile is possible ?

No. Just a way to filter out the library functions from things we need to try to understand. My expectation is that we'll eventually start working on a new firmware (either based on 9x firmware or from scratch), and we really don't need to know that much to do that. The main things we need are:
a) know how to display to the screen
b) know how to receive input from the screen
c) know how to interact with buttons and switches
d) know how to interact with the joysticks
e) know how to interact with the Tx module
Ideally, we'll want to reverse the walkera protoco (probbal via SPI)l, but that isn't strictly necessary, since we could probably use their code as if it were a tx/rx library.

To do all of the above, we only need: how to write a custom dfu (done?);how the various bits are connected to the MPU (in progress); a protocol to send to the CYRF6936 (not started), spec-sheets for all peripherals (available).

Originally Posted by PhracturedBlue

No. Just a way to filter out the library functions from things we need to try to understand. My expectation is that we'll eventually start working on a new firmware (either based on 9x firmware or from scratch), and we really don't need to know that much to do that. The main things we need are:
a) know how to display to the screen
b) know how to receive input from the screen
c) know how to interact with buttons and switches
d) know how to interact with the joysticks
e) know how to interact with the Tx module
Ideally, we'll want to reverse the walkera protoco (probbal via SPI)l, but that isn't strictly necessary, since we could probably use their code as if it were a tx/rx library.

To do all of the above, we only need: how to write a custom dfu (done?);how the various bits are connected to the MPU (in progress); a protocol to send to the CYRF6936 (not started), spec-sheets for all peripherals (available).

Well I am going to start looking over the 9x firmware code, and see what I can learn and gleam from it to prepare for the Devo version... I am going to keep my eyes open as you guys figure out the hardware, though a lot of it is greek to me

Originally Posted by NorCalMatCat

Well I am going to start looking over the 9x firmware code, and see what I can learn and gleam from it to prepare for the Devo version... I am going to keep my eyes open as you guys figure out the hardware, though a lot of it is greek to me

I'd also recommend reading through the ST Peripheral Library documentation and looking at the examples. That is almost certainly the easiest way to get up and running quickly.
http://www.st.com/internet/com/SOFTW...periph_lib.zip