Originally Posted by bytemuncher

My Devo 6 (10mw version as I live in Japan) with 6s firmware can receive telemetry data at least 50m distance. I would have gone further away, but the mini cp was getting too small to see.

Some of the Devo's 6's apparently have the new module in them.

Originally Posted by Atomic Skull

Some of the Devo's 6's apparently have the new module in them.

How so?

Originally Posted by OnceAFly

How so?

Maybe they have a paper based inventory control system?

My screen shots:



Thanks Derek for antenna mod.

Originally Posted by PhracturedBlue

I just played with mdisasam, and it does seem to work, though it would take a lot of post-processing to convert it to something useful.

If you want to use it:
take the 1st 0x125 files off the dfu file (that is 293 bytes). I did it using:
dd if="DEVO-8 FWDT v0.6B.dfu" bs=1 skip=293 > DEVO-8-FWDT.bin
now you can disassemble but you can't do the entire file at once. The reason is that there seem to be non-code sections that confuse the byte-parser.

But if you do:
mdisasm -a 0x8000000 -o 0x4146 DEVO-8-FWDT.bin

it will properly disassemble the reset code.
If someone has some minimal coding skills, they could probably use this to make a crude version of what IDA does by following branch pointers and running mdisasm on each section to build the 'full' disassembly.

I'm not sure of the value compared to just waiting for someone to post a disassembled IDA dump, but if you want free, and are willing to do a bit of leg work, this could get you going.

That's about all for me though. However, if it is helpful, here are the subroutine code-locations identified so far:

Thanks!

I've got a question for you: as I see, the DFU image element prefix defines, that the destination address of the firmware is 0x08004000. Shouldn't we start the addressing there?

Originally Posted by FDR_

Thanks!

I've got a question for you: as I see, the DFU image element prefix defines, that the destination address of the firmware is 0x08004000. Shouldn't we start the addressing there?

I haven't yet had time to actually look at the code generated. i had originally tried loading the code at 0x8004000, but it didn't make much sense, so i just explained how to reproduce rch4x0r's results.

I just looked at the DFuSe spec, and i see it should indeed load at 0x8004000, but the code I see doesn't make any more sense than it did last time (there is no question that the code section starts at 0x125 offset in the dfu file though).

I need to spend some time actually looking at the code, but a cursory glance shows that neither address makes much sense for the reset vector (0x8004146)

Maybe rch4x0r can answer why he loaded the code at 0x8000000
The bootloader must define the starting address, but I'm not sure if you can read that out even with the debug port (I've done minimal work actually interfacing with Arm hardware), but it should make it easyto determine where the code is actually loaded. I don't have a Devo radio yet, so I can't help at all there.

Hello ..
Me and friends in Brazil are following the forum, you could take a doubt, would rescue the memories of eight models I modify and resubmit it would be a start to program it on your PC.
Same is ER9X
I have 8S and I wanted to change the desktop background ...

#1 You shouldn't take anything I say as Gospel

Section 3.4 Reference Manual:

Depending on the selected boot mode, main Flash memory, system memory or SRAM is
accessible as follows:
● Boot from main Flash memory: the main Flash memory is aliased in the boot memory
space (0x0000 0000), but still accessible from its original memory space (0x800 0000).
In other words, the Flash memory contents can be accessed starting from address
0x0000 0000 or 0x800 0000.
● Boot from system memory: the system memory is aliased in the boot memory space
(0x0000 0000), but still accessible from its original memory space (0x1FFF B000 in
connectivity line devices, 0x1FFF F000 in other devices).

Also:

The embedded boot loader is located in the System memory, programmed by ST during production.

What I understand from this is:
1 The Bootloader is in system memory (not main flash). This appnote confirms that .
2 The Bootloader doesn't run in normal operation
3 We should be able to get at the bootloader code

It also looks like the bootloader requires a reset to jump back to application code. Is there a button to press at power on that puts the Tx into DFU update mode? I think there must be, DFU is part of the bootloader...

If I am right & we are booting directly from main flash then the Exception Vector table _has_ to be at address 0x08000000, this is aliased by the HW to 0x00000000 and the mcu loads the initial SP from 0x00 and the reset vector from 0x04. That's why I think this code is loaded at 0x08000000.

Alternately, Walkera implemented their own bootloader that live at 0x08000000 and that contains the real Exception Vector table, it would then jump to the application code & something copies the EV table..... Question is why would you bother? To add DFU maybe? It's not clear from the app note if this STM device supports DFU natively

This actually makes a bit of sense, if we assume the EV table from the DFU file does live at 0x08004000 then there are lots of infinite loops (many EV table entries point to 8004167 => offset 0x166 for example) which is a classic way to handle certain unused or fatal exceptions.

I have to get my Champ out of a tree, more later.....

Thanks again rch4x0r,
I haven't worked with ST chips, so I had assumed that it worked like other bootloaders where the bootloader starts, and jumps to the program memory, which would mean they had the opportunity to change the vector table. It is hard to reconcile what the dfu header says with loading at 0x8000000, and when I look at the code, all the references I see refer to addresses > 0800 4000. For now I'm going to assme the dfu is telling the truth, and load the memory at 0800 4000. It will be obvious as soon as someone dumps the memory with the debug port.

Alternatively, it may be possible to dump the memory over usb using dfu-utils.
It appears to be bi-directional, and they claim it supports DfuSe
Anyone with a Devo-8 or Devo-12 want to try it?

'dfu-util -l' should show your radio when connected via usb I guess (if you need to enter programming mode, you should do that 1st..I don't know the programming procedure)

'dfu-util -U firmware' should download the firmware from the device

You can find dfu-utils for all platforms here:
http://wiki.openmoko.org/wiki/Dfu-util

By the way there is new firmware available for the Devo8 (v0-.7) as well as for the Devo-10 (0.4). A quick check shows they all load to the same address.

I bought a Devo-8 from someone on the forums, so I should have it in about a week, and I can investigate further then.

With respect to the debug port, it should support JTAG and SWD:

Serial wire JTAG debug port (SWJ-DP)
The ARM SWJ-DP Interface is embedded, and is a combined JTAG and serial wire debug
port that enables either a serial wire debug or a JTAG probe to be connected to the target.
The JTAG TMS and TCK pins are shared respectively with SWDIO and SWCLK and a
specific sequence on the TMS pin is used to switch between JTAG-DP and SW-DP.

Thre is also this, which I have never heard of befoe:

The ARMŽ Embedded Trace Macrocell provides a greater visibility of the instruction and
data flow inside the CPU core by streaming compressed data at a very high rate from the
STM32F10xxx through a small number of ETM pins to an external hardware trace port
analyzer (TPA) device. The TPA is connected to a host computer using USB, Ethernet, or
any other high-speed channel. Real-time instruction and data flow activity can be recorded
and then formatted for display on the host computer running debugger software. TPA
hardware is commercially available from common development tool vendors. It operates
with third party debugger software tools.

I noticed from pics posted previously that only 2 wires are brought out to an unpopulated header (I assume it's for dbg). IIRC they are TCK & TMS which also double up as the SWD signals. I think SWD is adequate for our purposes & wont require attaching wires to pins

If someone could try dumping their radio using DFU that would be great

Yes, I am trying to unpack, but don't have tar...
Tar download is in tar.gz format!

Edit: Managed, but there is only surce in that...

There's an ST specific (DfuSe) tool that runs on Windows and will allow you to upload from your device

Manual: http://www.st.com/internet/com/TECHN...CD00155676.pdf

Tool in the design support tab

http://www.st.com/internet/mcu/product/164492.jsp

Originally Posted by FDR_

Yes, I am trying to unpack, but don't have tar...
Tar download is in tar.gz format!

Edit: Managed, but there is only surce in that...

Try http://www.7-zip.org (if you're on Win - or any other OS ... I just checked the unofficial binaries!!).

Originally Posted by rcH4x0r

There's an ST specific (DfuSe) tool that runs on Windows and will allow you to upload from your device

Manual: http://www.st.com/internet/com/TECHN...CD00155676.pdf

Tool in the design support tab

http://www.st.com/internet/mcu/product/164492.jsp

Yes I have and use that tool too, but that is not much different from Walkera's update tool, just you get all the model data in one config file, but at least it works (Walkera's crashes on my Vista if I want to "upload" a model config to my PC).

It shows three targets:
00: Internal Flash, 120x2k sectors 0x08004000-0x0803FFFF
01: SPI Flash: Config, 12x4k sectors 0x00002000-0x0000DFFF
02: SPI Flash: Library, 63x64k sectors 0x00010000-0x003F0000

rc.fdr.hu/pictures/dfuse_devo8.png


Edit: I've just looked into the fw dfu's data, wich I've got with this tool, and it is all FF everywhere! It looks like it doesn't allow you to look into the fw...
However the config (model data) is fine...