Advanced Search

Wondering the same thing. I'm usually in Linux all day long and only boot in Windows to use flash my Devo 10.

I know some people used the mac dfu-utils with success but I've been afraid to use it on mine since I only have 1 TX and no equipment to relfash a bootloader f.e.

some quick news:

- TX is CYRF6936 but has only 7 pins
- Display is a TG12864Z 128x64 dots but has also NT7538 controller
www.tronpok.com/uploads/12864Z.pdf

After only a quick inspection the wiring could be identical or at least very similar to Devo 10

If somebody has an idea where to get the bootloader i probably try to flash the Devo10 Version of deviation and see what happens...

H. wrote: What about desoldering the CPU and replace with STM32F103VCT6. They have the same pinout so it should work.
Is it possible or do we need some magic from Walkera?

Like dehalo i wouldn't mind trying it if it's not too complicated because i bought 7E for only one reason: Burn deviation onto it.

I assume you mean the RCT6?
If the 7e has a RBT6, then it should have a LQFP64 package. The high-end part in that package would be a 103RCT6, 103RDT6, or 103RET6. If you have the ability to desolder an LQFP package and install a new one, then the rest shouldn't be too bad (most people do not have the necessary equipment to do that)

Basically:
a) install a new bootloader (probably the Devo10 bootloader, but we could use the stock ST one too)
b) figure out which Display chipset is used and see if we need something different there
c) figure out the pin mapping for the 7E I/O
You could use ISP for that, though it'd probably be easier to do with SWD.

Good point... what did he use to reflash the bootloader and where did he get it?

MatCat wrote: Yeah I looked at the makefile and figured it out, nice there is even a flash option in the make .

Be very wary of that. wusselfuzz put it there and said it worked on his Mac. I've never tried it myself. At least one other user bricked his Devo8 (needed to reflash the bootloader) with that tool (though not using 'make' to do so)...I'm not sure how that is possible, but there you go. I always use the Windows tool to upgrade personally

There are 2 things stopping me from suppoting the Devo7e:
1) There is no firmware released for it from Walkera. That means you couldn't go back to the official firmware, but it also means that the current DFuSe tool does't actually support the 7e, so there is no tool to do the upgrade today. That wouldn't be a problem for me, since I could flash the bootloader, but most people wouldn't want to do that.
2) I don't have one yet. I will resolve that as soon as (1) is available.

I have quite a but of knowledge about the bootloader, so depending on what tools you have available, I can tell you quite a bit about it. Alternatively, it should be easy to load the STMicro bootloader easily enough. the differences between the reference bootloader and the Walkera one are primarily related to:
a) specifying the model name
b) displaying the splash screen
c) verifying the checksum

None of which is strictly necessary.

PhracturedBlue wrote: Good to hear!
As I've said before, the 1st thing to do is not to panic! I've only heard of one person actually breaking their Radio during upgrade, and that was using the linux dfu-utils (which I do not recommend). I believe they solved it by flashing and reprogramming the bootloader so it wasn't terminal.

That was me
My problem looks exactly the same. The hardest thing is that I have no mative Windows machine at all. I soldered a pin header for the JTAG connector to my Devo 8 and started to experiment with its bootloader, so strictly speaking it is not unbricking. It worked, however. Then I intentionally bricked it again to better study the bootloader.

Good to hear!
As I've said before, the 1st thing to do is not to panic! I've only heard of one person actually breaking their Radio during upgrade, and that was using the linux dfu-utils (which I do not recommend). I believe they solved it by flashing and reprogramming the bootloader so it wasn't terminal.

I'm pretty sure the upgrade failed and the checksum is wrong. For some strange reason dfuse does not see the TX anymore while dfu-util still does. Looks like the TX's bootloader is stuck in some strange state preventing it from normal upgrade.

I think I'll better treat the CPU as empty and reflash everything. At least it will be readable then. Probably I'll end with a custom bootloader

Are you sure you upgraded (rather than uploaded) the Devention firmware using Walkera's dfuse tool? The only reason it would boot right to the bootloader is if (a) the ext button was stuck or (b) the checksum was wrong. The dfuse tool from walkera will always write the right checksum (this is not true of the dfuse tool from STM)

Tried Windows, still no success even with native Devo firmware. The TX just does not leave upgrade mode at all even after removing the battery.

Now going to use JTAG to reflash everything including the bootloader.

kohansey wrote: Is it possible to directly download and debug the code into the transmitter?

It is possible but difficult, and not very useful.
1st you need to download the bootloader. You do this by creating a custom image using the dump_bootloader.c code
Once you have a copy of the bootloader, you need an SWD debugger (I use an STLink/v2) JTAG is not supported.
You now use the SWD debugger to reset the MCU FLASH. This will zero out all FLASH, but also reset the read-only bits and enable debugging
You can now use the SWD to re-upload the Bootloader.

At this point you can use the SWD interface to do debug, but the CPU runs at slow-speed (messing up timing) and the interrupt-driven network stuff makes a mess generally, so you probably want to turn that off. In the end it was next to useless for me, since at least the STLink/v2 is very limited, especially when paired with gdb.

I've found that I do virtually all of the programming via the emulator, and do all debug through the UART, and that it generally works well.

Also I recommend wiring up a switch to the battery lead. I've worn out the plug on my devo8 since I end up unplugging a lot to get out of a hang (the watchdog helps with this but does not eliminate it)

Cool, is there documentation on what needs to be done so the bootloader accepts it? Documented in source at least? Could you point to where I could look to see how it is currently done?

Disassembling the firmware should not be necessary for enabling the Devo12. The important piece is to be able to generate the dfu such that the bootloader will accept it, and we know how to do that now.

I've built the emulator, but it crashes immediately on Windows:

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.

Why does the main loop read media/devo8.bmp repeatedly?

I just checked in a bunch of changes.

The GUI is now functional on hardware. The tx can act like a USB drive. Press R+ to turn on/off USB mode (in USB mode, the rest of the tx is disabled because USB uses up too many resources to be able to do anything else while it is active

The firmware now has filesystem support. You can copy a bmp to the tx from the PC, and have it be used by the GUI.

Edit: Note that you'll need to format the USB drive the 1st time you activate USB mode and plug into a PC. I've only tried it on Windows, but it works properly. Do not change teh sector size from the default (it'll come up at 4096). It will also corrupt the bootloader image. I thought I'd reserved enough space for it, but apparently I messed it up.

Well, after another few days of fighting with it, I finally can use my Transmitter as a 4MB USB drive.
I was not able to get the LPCUSB port of the mass-storage driver to work reliably. It seemed to mostly work, but it loses packets and gets lost. In the end, I used the STM32 refernece driver. We probably should spend some more effort to get the lpcusb version working, as it is actually implemented against libopencm3, but I've banged my head against it for too long to spend any more effort on it now.

Besides the driver stability, I also found a bug in the spi_flash code that prevented reading bytes from flash, and I missed the fact that the SST flash initializes with the upper banks locked. I spent many more hours trying to figure out why my writes weren't being applied, but they worked fine in main(). This happens because 'main' executes as part of the power-down sequence after uploading a new firmware, and the bootloader unlocks all banks. So programming was happening during shutdown after firmware upgrade, but it wouldn't work during normal operation. Ugh.

anyhow, now on to the next step of getting FAT support working internally so I can read the files I just put on with my PC...