HobbyKing.com New Products Flash Sale
Reply
Thread Tools
Old Apr 03, 2012, 03:46 AM
Registered User
Joined May 2011
657 Posts
Quote:
Originally Posted by OnceAFly View Post
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...
FDR_ is offline Find More Posts by FDR_
Reply With Quote
Sign up now
to remove ads between posts
Old Apr 03, 2012, 04:03 AM
Registered User
Joined May 2011
657 Posts
Quote:
Originally Posted by PhracturedBlue View Post
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...

Quote:
Originally Posted by PhracturedBlue View Post
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
FDR_ is offline Find More Posts by FDR_
Reply With Quote
Old Apr 03, 2012, 04:06 AM
Better then Sliced Bread!
NorCalMatCat's Avatar
United States, CA, Arcata
Joined Oct 2011
2,650 Posts
Quote:
Originally Posted by FDR_ View Post
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?
NorCalMatCat is offline Find More Posts by NorCalMatCat
Reply With Quote
Old Apr 03, 2012, 04:06 AM
Registered User
United States, TN, Memphis
Joined Dec 2011
870 Posts
Where's the donate button?
itsmillertime is online now Find More Posts by itsmillertime
Reply With Quote
Old Apr 03, 2012, 04:15 AM
Registered User
Joined May 2011
657 Posts
Quote:
Originally Posted by NorCalMatCat View Post
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...
FDR_ is offline Find More Posts by FDR_
Last edited by FDR_; Apr 03, 2012 at 05:01 AM.
Reply With Quote
Old Apr 03, 2012, 09:28 AM
Registered User
Joined Jan 2012
682 Posts
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.
PhracturedBlue is offline Find More Posts by PhracturedBlue
Reply With Quote
Old Apr 03, 2012, 09:45 AM
Registered User
Joined May 2011
657 Posts
Quote:
Originally Posted by PhracturedBlue View Post
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...
FDR_ is offline Find More Posts by FDR_
Reply With Quote
Old Apr 03, 2012, 09:54 AM
Registered User
Joined Jan 2012
682 Posts
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.
PhracturedBlue is offline Find More Posts by PhracturedBlue
Reply With Quote
Old Apr 03, 2012, 10:37 AM
Registered User
Joined May 2011
657 Posts
Quote:
Originally Posted by PhracturedBlue View Post
....
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...
FDR_ is offline Find More Posts by FDR_
Last edited by FDR_; Apr 03, 2012 at 10:44 AM.
Reply With Quote
Old Apr 03, 2012, 11:02 AM
Registered User
Joined Jan 2012
682 Posts
Quote:
Originally Posted by FDR_ View Post
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.
PhracturedBlue is offline Find More Posts by PhracturedBlue
Reply With Quote
Old Apr 03, 2012, 01:25 PM
Registered User
Joined Jun 2010
120 Posts
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
rcH4x0r is offline Find More Posts by rcH4x0r
Reply With Quote
Old Apr 03, 2012, 01:58 PM
Registered User
Joined May 2011
657 Posts
Quote:
Originally Posted by PhracturedBlue View Post
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...
FDR_ is offline Find More Posts by FDR_
Reply With Quote
Old Apr 03, 2012, 03:58 PM
Registered User
Joined Jan 2012
682 Posts
Quote:
Originally Posted by rcH4x0r View Post
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
PhracturedBlue is offline Find More Posts by PhracturedBlue
Reply With Quote
Old Apr 03, 2012, 04:30 PM
Better then Sliced Bread!
NorCalMatCat's Avatar
United States, CA, Arcata
Joined Oct 2011
2,650 Posts
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
NorCalMatCat is offline Find More Posts by NorCalMatCat
Reply With Quote
Old Apr 03, 2012, 06:52 PM
Registered User
Joined Jun 2010
120 Posts
Quote:
Originally Posted by PhracturedBlue View Post
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...
rcH4x0r is offline Find More Posts by rcH4x0r
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Wanted Broken Walkera Devo and Spektrum tx itsmillertime Aircraft - General - Radio Equipment (FS/W) 1 Mar 20, 2012 05:37 AM
For Sale Walkera Devo 7 TX/Devo RX2625H Combo for sale Tom Z Aircraft - General - Radio Equipment (FS/W) 0 Oct 06, 2011 01:33 PM
For Sale Walkera Devo 7 TX/Devo RX2625H Combo for sale Tom Z Aircraft - Electric - Helis (FS/W) 0 Oct 05, 2011 12:38 PM
Discussion New Walkera Devention Devo 12 TX w/ Touch-Screen hobbypartz Radios 2 May 09, 2011 12:38 AM
Discussion New Walkera Devention Devo 12 TX w/ Touch-Screen hobbypartz XHeli 0 May 06, 2011 12:19 AM