Advanced Search

Reading that does suggest I need to reflash the DFU bootloader to proceed with reloading Deviation? How/where do I find the DFU bootloader .bin file?

An update on this problem I was having, after more tests on the main board it has revealed that the MCU is burnt and I need to replace the STM chip. I need to know how do I proceed after replacing the chip, how do I get the DFU bootloader back and how's the connection and tools/software to do this?

If you have turned off the radio, unplugged the battery (2 seconds is enough), made sure the battery is fully charged, plugged it back in, pressed ENT and with it held down turned on the radio.
If you did all that and your radio doesn't enter firmware mode, there are 2 possibilities I can think of:
1) The power circuit is broken and the radio isn't turning on.
2) The bootloader was somehow corrupted

you need to distinguish between these 2. The only way to do so is to open up the radio and measure the voltage with a voltmeter.
If the voltage is correct, then the bootloader needs to be replaced. That requires a programmer. you can buy one from china for about $6US (search for st-link v2)
Unfortunately on the devo10 they don't install terminals, so hooking up the programmer involves soldering to the board. I can explain the steps in detail if you elect to go this way.

I don't know what your comfort level is with something like this. There are quite a few steps involved.

You have other options:
a) contact your retailer and ask them for help
b) contact Walkera and ask them for help
c) you can ship it to me and I will do everything in my power to make it work again. You pay shipping both ways. This is probably only feasible if you live in the USA.

Looking for help,

I tried to upgrade my Devo 10 (transmitter) and I uploaded the wrong file, when I tried to go to the second part pressing Power + ext, the transmitter did not powered on.

I removed the batteries and replaced them with new set, waited few hours to retry, it did not work.

I open the transmitter and Follow the wires coming from the batteries to the switch and there is power there.

I was told the bootloader my be gone, if anyone can help I will highly appreciated.

I think there must be some bootloader there. I tried using a serial cable once on it which should have worked if they used the builtin bootloader, and it didn't detect. But I agree, it would be worth a shot.

Does the DEVO 7 have a bootloader at all?
It is programmed directly using the UP-02 adapter, not throw USB...

I would try to install the A fw and see what happens. It might not work, but then you should be able to reinstall the B fw...

There are 2 versions of the Walkera transmitters '10mW' versions and '100mW' versions. This is true of the Devo8 and 10. The '10mW versions use the 'B' firmware, the 100mW use the 'A' firmware. I believe these are the 'A' and 'B' values found in the battery cover, but really I'm not sure. I do not know if this holds for the Devo7 as well. The difference between the A and B models is a programmed byte in the bootloader, there is no physical difference, but you cannot load an A firmware on a B Tx, and changing the bootloader is non-trivial on a Devo8 or Devo10. I don't know the impact on a Devo7.

@victzh

Wow - sounds interesting and promising!
Yes, I got several different nRF24L01 PCBs and plenty different ATMEL AVR chips.
I also got a few Arduino boards (Nano) but I hate to work using Arduino development environment.
All projects I've done so far (RC model electronics up to 8 kB code size) I always implemented in assembler using ATMEL studio 4 and 6.

So for me the easiest would be if you tell me:
a) the required AVR chip
b) the needed pinning in between AVR port pins and RF module
c) the needed fuse settings
d) the needed external crystal frequency (if not the internal one gets used)
d) a HEX file for the specified controller

In this case I would do a manual wiring / proto assembly and a direct flash programming of the controller without Arduino bootloader stuff.

Is something like this possible for you?

(Attached just for orientation two impressions of typical micro modelling electronics I've done)

I promise I checked for new a nightly build before replying before it was not there yet

Downloaded the new Devo 7e nightly in a clean directory (just in case), modified hardware.ini, same problem (see picture and the hardware.ini I used)

The interesting things is that when I launch the emulator, for the briefest moment before the Deviation bootloader image shows on the simulated screen, I see the right values in SW A and B, to be replaced with -100 halfway thru the boot process, and well before the model icon appears

Would you mind checking the new nightly build and see if it works for you? www.deviationtx.com/repository/Deviation...-v4.0.1-75f640d.zip/ I really have no idea what else to try, it's all pretty standard and can't see any mistake (which is different than saying that there is none )

look at common/devo/power.c:We define VECTOR_TABLE_LOCATION for each transmitter. This is needed because the F1 has a bootloader.

For the F2, I don't need to set it, since the default is at 0x0000 which is where we put it. You should be able to use it there as well I'd think.

PhracturedBlue wrote: Well, I already found one bug in my schematic. The CSN pin cannot be overloaded onto !RESET without setting the RESET-DISABLE fuse, which would then render future programming impossible.

There's a really tiny UART bootloader for the ATtiny85 which you might be able to port. That could let you burn the reset fuse but still program the chip.

Perhaps you could even get it so that you could program it from the STM32, by dumping a new file onto the mass storage, or adding a virtual serial passthrough mode.

I'm working on porting Deviation to the STM32F3 (and possible F4) series of processors, with the goal of being able to use it as a retrofit "brain transplant" for existing transmitters or custom builds using salvaged sticks.

Rationale: With the exception of the Devo 7e and the x9d, current platforms are fairly pricey. The Devo 7e is extremely limited in program flash. And even an affordable transmitter is not a great development platform, since one wants to keep something in flying condition...

New CPU: The STM32F103 is not a bad processor, but has a couple of limitations:

- no cheap eval board with the pins broken out
- USB bootloader is an aftermarket add on, and susceptible to corruption
- limited memory options

Moving to an F3 or F4 provides some improvements:

- cheap Disovery eval boards ($10 F3, $15 F4) though they are too big for an existing TX enclosure unless one removes the pins
- permanent USB dfu bootloader already in the chip from the factory
- faster CPU
- outrageous amounts of memory available (f4)
- USB host mode for talking to older android phones, flash sticks (F4)

LCD possibilities:
- 1.8" SPI color LCD ($10 from adafruit, $20 /w breakout)
- 320x240 touchscreen LCD's (~$25, but parallel interface)

I think you are right, but the code I found does this:288 is half a PAL screen-height, so I was assuming this was writing a 8x288 image to the screen.

When I look at the Bootloader startup, it uses 2 fonts, a large one for DEVO-F7 and a smaller one for 'devention Program Update . . . .'. Looking at the documentation I see the large font is supported (I assume the small one is too but I don't see the bitmaps for it).

Edit: Looking at the data sheet, I guess it is writing 12 lines by 24 columns = 288 elements, which enforces your statement.

I got my 9XD today.
I've already started work porting Deviation to it, but it will take some time.
The processor is an STM32F205VET6 (60MHz, 512k Flash, 128k RAM)
The display is an RMG21264-01 212x64 display. The LCD Driver is an ST7586S

Having all of the source code available will make it a lot easier, but there are some differences between the STM32F103 and STM32F205 chips I need to understand, and figuring out how the buttons, flash-drive, etc are connected will take some time.

Unfortunately with a 212x64 display, it probably means yet another display layout, since I don't see an easy way to reuse the work we've done on the 128x64 on a 212x64 display. That will have to wait until I've got the hardware figured out.

It looks like programming uses the (stock) STM32 DFU uploader. I was able to download the Flash using it, so uploading should be straight forward. Looking at the hardware, it appears the STM32F205 has a built-in USB bootloader, so there is no software bootloader.

There are several ICs on the main board I haven't identified yet. May or may-not be relevant:

Both of these are from the same manufacturer. Logo looks like a butterfly?
U3: 31 5401
U4: 711 2BT A7H8

STMicro: 456 RP B305
(there are others I can't read the ID on)

I started putting together an article on this Tx as well

The 2 pins of the STM32 chip being shorted is normal. make sure they are actually shorted, I've seen tx that have a much bigger blob of solder connecting them. I haven't ever seen solder markings on the pads you mention. Those are the pads used to re-flash the chip (it enters the chips' service mode). If there are markings there, it indicates the STM32 has likely had the bootloader re-flashed since assembly. I can't tell from your pic what is going on near the crystal (the metal oval above the chip). Is that another solder mark? That might imply the crystal has been replaced as well.

Where did you get your Tx? It definitely appears to have been serviced at some point. Did it have an unbroken seal when you purchased it?

PB, could you help him with the bootloader perhaps, so he could make and use a standard deviation dfu?

I think the devo7e bootloader won't work, because it always show something on the screen. Since they have a different screen, with different drivers that won't work

But yeah maybe it works without screen, that's possible.

I was suggesting if you load bootloader and it shows its self on your system you could maybe use the devo7e loader ?? Just a thought.

yes, except he wiped the bootloader when he replaced the MCU. Even still, getting the bootloader shouldn't be an issue.

Did you replace the MCU with the same one that was there? Or did you use one of the larger ones with more ROM?

You can't read the bootloader, because the controller is read protected, but you can write a small program, which copies it to the flash, and then read that with the STM (or Walkera) DfuSe util...