Originally Posted by OnceAFly

Hum...May i ask how you get the 801 to bind on devo6? I have the latest firmware 0.5 and it only bind on 802 not 801...

I guess he meant the rx firmware should be new! So according to him there might be different versions of the rx801...

Originally Posted by PhracturedBlue

Well, I've got my Devo-8 and STLink/V2 now. I'll be playing with it tonight, and hopefully will have something to report out soon.

I'm glad you have it finally...

Originally Posted by PhracturedBlue

Unfortunately, I immediately hit a road-block...
The ST-Link software can see the STM32F103VCT6, but I immediately get this:
...
It doesn't stay connected long enough for me to be able to be able to do anything else
I don't really know much about the STLink or the memory-protection available in these processors, so I'll likely do some reading on that and see what options we may have.

So that's why the ST's DFU tool saved the firmware with all FF in it...

To write the fw from strach, we should know a little more about the surrounding hardware such as the display handling. (I guess the buttons are easier to discover...)
More importantly the protocols should be reverse engineered too...

In the meantime I am working on the model data mapping. Half of it is done already. It's just so boring: change something, turn off (beep), turn on in DFU mode, select and name a destination file, download it, leave DFU mode (beep-beep), compare the file to the default, change the setting back, change an other setting, repeat x1000

Originally Posted by FDR_

I'm glad you have it finally...



So that's why the ST's DFU tool saved the firmware with all FF in it...

To write the fw from strach, we should know a little more about the surrounding hardware such as the display handling. (I guess the buttons are easier to discover...)
More importantly the protocols should be reverse engineered too...

In the meantime I am working on the model data mapping. Half of it is done already. It's just so boring: change something, turn off (beep), turn on in DFU mode, select and name a destination file, download it, leave DFU mode (beep-beep), compare the file to the default, change the setting back, change an other setting, repeat x1000

Is that stored in the library?

Where's the donate button?

Originally Posted by NorCalMatCat

Is that stored in the library?

No it's in the config.
With Walkera's DFU Upgrade Tool one could save the model data (for each selected model one by one) to the computer into a *.bin file, but it crashes on my 32 bit Vista every time I try, so I use ST's own DFU demo to save the whole config area (all the 12 model) into a dfu file.
You can find a download link to it here:
http://rc.fdr.hu/devo.php#technical_data

Edit: I've just counted, so far only about 250 byte known of the total 912...

A couple other things:
1) The processor is not programmed from System memory. The BOOT0 pin is tied low which means that the processor always boots from Flash. The BOOT0 pin is tied (through a 10k resistor) to a jumper 'CON2' on the right edge of the board (above DETC). Attaching a jumper will allow the processor to boot from System Memory. BOOT1/PB2 is also tied low (through a 10k resistor, no jumper) so there is no way to boot to RAM without soldering on a jumper

2) PB2 is also attached to the CE# (chip enable) of the 32MBit SST25VFO32B Serial Flash chip. There is no mechanism to read-protect this chip, so it should be easy to dump its contents by attaching an SPI device to it. I don't have one sitting around, but can whip something up if need-be. It should also be possible to hook up a logic-analyzer and read it while it is being programmed. It does not appear that the serial flash will have any code. most likely images or model memory.

I think the above makes it clear why they have their own boot-loader:
a) they want fancy graphics while in USB mode
b) they need to be able to program the serial-flash chip
c) They wanted to allow dfuse programming whith read-protection enabled(?)
d) They wanted to restrict which memory areas could be programmed

I'm not sure why they implemented it in DFuSE format in this case though. I wonder if they used a pre-made bootloader.

Originally Posted by PhracturedBlue

A couple other things:
1) The processor is not programmed from System memory. The BOOT0 pin is tied low which means that the processor always boots from Flash. The BOOT0 pin is tied (through a 10k resistor) to a jumper 'CON2' on the right edge of the board (above DETC). Attaching a jumper will allow the processor to boot from System Memory. BOOT1/PB2 is also tied low (through a 10k resistor, no jumper) so there is no way to boot to RAM without soldering on a jumper

2) PB2 is also attached to the CE# (chip enable) of the 32MBit SST25VFO32B Serial Flash chip. There is no mechanism to read-protect this chip, so it should be easy to dump its contents by attaching an SPI device to it. I don't have one sitting around, but can whip something up if need-be. It should also be possible to hook up a logic-analyzer and read it while it is being programmed. It does not appear that the serial flash will have any code. most likely images or model memory.

I think the above makes it clear why they have their own boot-loader:
a) they want fancy graphics while in USB mode
b) they need to be able to program the serial-flash chip
c) They wanted to allow dfuse programming whith read-protection enabled(?)
d) They wanted to restrict which memory areas could be programmed

I'm not sure why they implemented it in DFuSE format in this case though. I wonder if they used a pre-made bootloader.

I think the model config and the library are in the serial flash according to the ST DfuSe:


The update screen made me think they implemented their own update, but it is possible they boot from their flash, show the screen, and then call the standard DFU updater in some system ROM, isn't it?
However there are plenty of code space from 0x08000000 to 0x08004000 to do it...

I'm going to guess they used the bootloader defined in UM0424:
http://www.st.com/internet/com/TECHN...CD00158241.pdf
http://www.st.com/internet/com/SOFTW...ARE/um0424.zip

A quick look-over seems to imply it is designed for what they need to do. Maybe looking over the code, it is possible to find a hole that would let us read the Flash memory. More likely we'll just do it another way. I'm still very confused about why the main dfu files can't be properly disassembled though.

Originally Posted by PhracturedBlue

....
I'm still very confused about why the main dfu files can't be properly disassembled though.

Probably because the program doesn't start there.
It contains data and resources too, which might confuse the disassembler...

Edit: BTW, you are right, it seems that the DFU should be implemented by the user (ie Walkera).
The sample code in the "\STM32_USB-FS-Device_Lib_V3.3.0\Project\Device_Firmware_Upgrade\ " dir of the um0424.zip...

Originally Posted by FDR_

Probably because the program doesn't start there.
It contains data and resources too, which might confuse the disassembler...

Well, the vector table is quite clear as to where the reset entry-point is, and the documentation for the bootloader says that the vector table position follows the spec for the bootloader, but the functions there make no sense. Besides, I'm not sure why they would protect the CPU and then leave the DFU files wide-open to disassembly. I don't think it is quite as simple as not knowing where to start disassembly, but I certainly could be wrong.

One last note:
I tried entering system-boot mode (jumper on CON2), but was not able to get a response from the DFU or the STLink in this mode. Perhaps I'm missing something. Oh well. I'm done for the time being.

FDR_ confirmed we can modify the code and flash it back, it should be dead easy to copy the boot loader out of some port (UART maybe?)

Still waiting, I think it may be lost in the post tho

Originally Posted by PhracturedBlue

Well, the vector table is quite clear as to where the reset entry-point is, and the documentation for the bootloader says that the vector table position follows the spec for the bootloader, but the functions there make no sense. Besides, I'm not sure why they would protect the CPU and then leave the DFU files wide-open to disassembly. I don't think it is quite as simple as not knowing where to start disassembly, but I certainly could be wrong.

One last note:
I tried entering system-boot mode (jumper on CON2), but was not able to get a response from the DFU or the STLink in this mode. Perhaps I'm missing something. Oh well. I'm done for the time being.

That vector table might not be the one used.
Just like the libraries, which also have a resource table at the beginning, but some of that tables are plain wrong (for example in the DEVO 6 v0.3 lib), still the tx works just fine. They might not use that resource tables. They might use other vector tables, since AFAIK the code begins at 0x0800000...

Originally Posted by rcH4x0r

FDR_ confirmed we can modify the code and flash it back, it should be dead easy to copy the boot loader out of some port (UART maybe?)

Still waiting, I think it may be lost in the post tho

yeah, I was going to give it a shot tonight if I have time.
Potential Issues:
a) There is a minor chance of bricking the Tx if the bootloader doesn't work exactly how we think it does
b) we still need to find an entry point where code will actually execute

My thought was to use the SWD pins to create a crude SPI interface. They are easy to attach to, they aren't connected to anything else, and they are bi-directional. I haven't looked at where the USART goes, but that could also be a good choice

Stuff like this makes me wish I had studied hardware a little bit more... give me a code base with functions for hardware interface and I can whip together an awesome firmware... but the hardware stuff is slightly beyond me

Originally Posted by PhracturedBlue

yeah, I was going to give it a shot tonight if I have time.
Potential Issues:
a) There is a minor chance of bricking the Tx if the bootloader doesn't work exactly how we think it does
b) we still need to find an entry point where code will actually execute

My thought was to use the SWD pins to create a crude SPI interface. They are easy to attach to, they aren't connected to anything else, and they are bi-directional. I haven't looked at where the USART goes, but that could also be a good choice

Eh? We already know you can mod the FW & it still runs, not sure how you can brick anything.

Build a landing zone - lots of NOPs (or whatever in ARM world) and put the dump code at the end, CPU jumps into NOPs then runs into your payload, it doesn't matter where it jumps to

If you prefer you can always write to SPI flash and dump using DFU tool...