Advanced Search

I've updated the devof7 branch to use the dveofs filessystem.
djtance, you will want to turn that off.
in the devof7 target_defs.h, set:Hopefully it will work ok for you. I am now able to boot my devof7 using the devofs filesystem with the stock flash chip, so I can help with testing as needed.

I did run into a rather large annoyance. The bootloader does not seem to give full write access to the flash chip. In order to install the filesystem, I needed to build a custom image to copy raw data to the flash. That makes updating the filesystem really annoying. I have some ideas about working around it that I'll need to play with..

The deviation bootloader has code to prevent writing to the bootloader memory region. I have never overwritten the bootloader in all the testing I've ever done. If you have a STLink, you can restore the bootloader (I have the f7 bootloader if you need it) in an emergency.

To boot your code, you need to ensure you leave a hole at 0x 08005000 because the dfu code installs a checksum there. if you use the deviation devo7e.ld file, you should be ok.

I don't understand your Saleae logs. I would not ever expect to see clock with vdd low. I also didn't think that the hold or wp pins were even used on the Devo radio. I would expect them to be tied directly to Vdd. The CE transition doesn't make much sense with respect to the data I see either. So I can't help you with the logs you've provdided

After seeing several posts about users installing the wrong firmware on their transmitters, I decided to dust off my Uploader code and try to finish it.

Here is version 0.6. this is the 1st version with a functional GUI.

Features:

• It can upload zip files containing separate firmware and libraries, or the new format zip files that include both firmware and libraries (you don't need to go into the fiesystem mode after updating the dfu anymore)
• You can select whether to overwrite your tx.ini, hardware.ini, or models.
• It can format your drive for you
• It still supports DFU files if desired
• It will not allow you to upload firmware not intended for your transmitter
• cmdline mode is still available

It is slower to update the filesystem than using 'ENT' to go to USB mode because the bootloader only supports uploading in 64k chunks.

These things have not yet been tested:
Uploading Walkera official firmware zip files
Uploading to the Devo12
Detection of Devo F12, F12E, 12E, or F7 transmitters (I would be interested in how these transmitters show up on the screen but DO NOT try to install a dfu or zip on any of these transmitters!)

I would be really interested in anyone who could provide feedback on using it either usability, or bugs. I intend to make this the officially supported upload method for Deviation in the next release, so getting testing in would be really valuable.

NOTE: It should not be possible to irreversibly harm our transmitter using this software, but you need to ensure you have a known-good dfu file to install in case you need to go back to the Walkera DFuse installer.

This software does require that Java be installed, but should have no other dependencies. In Linux you must ensure you have USB permissions or run as root.

FYI, getting the UniversalTx running with a Devo radio is proving more difficult than expected. I've been struggling with stupid stuff like getting SPI slave mode to work (which I've never used before). I did find that I need to cut th A7105 MISO line (I dunno why I put it there in the 1st place), and I now have read operations working properly (I never did get it working with interrupts, but DMA seems fine). Something is still holding the MISO line, and I haven't figured out what it is yet, so the board won't respond back to the Devo Tx right now. Also, the usb detect still doesn't work reliably for unknown reasons. I need to pull the BOOT0 jumper most times to prevent entering the bootloader in normal mode. I don't get it. The pulldown resistor should be sufficient to prevent the need for that.

Anyhow, progress is being made, just slower than I'd have liked.

Thank you very much! At last, I still failed to download the USB DFU libopencm3, (It took me >2 hours for only 5% GIT cloned)
After programming your devo10bootloader.bin to 0x08000000, then the board can be detected by the "Devention DfuSe USB upgrade Tool" when pressing the EXT button, and then I can directly upgrade it to "deviation-devo10-v4.0.1".
Now my Devo10 is fixed. Thanks again !

Here is the devo10 bootloader (it is in raw bin syntax)

you need both the bootloader and an unencrypted version of the devo10 firmware.

I don't seem to have a copy of the devo10 bootloader on hand, but you can run any stock bootloader as long as it jumps to the right memory address. Here's one:
libopencm3.org/wiki/USB_DFU
Though Walkera uses a modified version of the STMicro bootloader (which you can also use without issue). Finding it is annoying because they continuously rework their website though. If you can't get any of that working, I can dump the bootloader from my devo10 when I get a chance, but it likely won't be right away.
Note that if you use a custom bootloader, you need to always decrypt the firmware, since the Walkera bootloader does that as part of dfu upload.

you can decrypt the walkera dfu via the dfu.py script that is included in the deviation repo

My Devo 10 get burned a few weeks ago, I have replaced the burnt 5V-to-3V regulator and the MCU (STM32F103VCT6), and I have the ST-link V2 to program the flash memory, But after programming the
hex file ("DEVO-10 Fw v0.7A.dfu" is converted to "DEVO-10 Fw v0.7A.hex" by "Dfu file manager"), the transmitter is still failed to power up, there is no crystal oscillation signal at the 8MHz crystal.
In "STM32 ST-LINK Utility", the flash memory is starting from 0x08004000 to 0x801EC87.
Now I see that the Boot0 pin is connected with a 10K ohm resistor to GND, hence it should boot from main flash memory 0x08000000.
But now the content of address 0x08000000 is blank, so it cannot start the program.
And I cannot find any information of the bootloader image and where it should be placed.
Does anyone has the experience to reprogram the blank MCU (STM32F103VCT6)?
Would you mind to share the memory content at 0x08000000?

Thanks in advance!

As a follow up to the above, I wonder if the significant difference between the Windows 7 computers which didn't recognize the 7E and the XP that does is that I have used both Windows 7 computers to upgrade a Taranis to OpenTX, and thus they already had STM Bootloader in the list of devices which USBDeview shows...maybe Windows did not load a proper driver to make the 7E visible to DfuSe?

As a follow up to the above, I wonder if the significant difference between the Windows 7 computers which didn't recognize the 7E and the XP that does is that I have used both Windows 7 computers to upgrade a Taranis to OpenTX, and thus they already had STM Bootloader in the list of devices which USBDeview shows...maybe Windows did not load a proper driver to make the 7E visible to DfuSe?

and thanks again aMax

I reattached the stm32 and fixed the 5v regulator. For some reason even without the boot0 jumper installed, I'm getting 3.3V on the boot0 pin, and the mcu won't exit the bootloader. If I pull the boot0 pin low, the board boots up and I see on the PPM pin:Which is the same thing SadSack was seeing. Now I'll start investigating whether the transceiver xtals are toggling or not, and we'll see where it goes from there.

What is the method, for full flash?
I think, flash the bootloader and so on.

The screen is good, working (i see it in bootload-er mode).
The processor good.
The flash good (if upgrade, and verify, then verify is ok.)

Any idea?
The return shipping cost to the goodluckbuy is very expensive.
And GLB is not an correct!!!

Thank you.
I allways use UPGRADE. Never update. I read manual before use tool.

I don't understand what is the problem.
Screen allways black, execpt the upgrade screen.

I Think the china's GLB try to upgrade an wrong firmware/lib.

How to re-flash the bootloader, and low level files?

The 12S is a little different than the rest of the Devo transmitters. The TRN switch is the one you activate for the bootloader, instead of the 'EXT' button. Your bootloader is correct.

When uploading the firwmare, make sure you use the 'Upgrade' button, not the 'Upload' button. The Upload button doesn't do what it's name implies. If you've used the 'Upload' button in the past, re-download the deviation firmware from the website before loading the firmware again.

I try to copy files to the transmitter.
But, windows not show new device, not found usb drive.
I try to push ENT or EXT buttoon with power on, but nothing.

My bootloader is odd.

The bootload show if i push TRN button for 2 sec.
(TRN=Trainer, not ENT or EXT)
ENT and EXT is not effect.

I'm clueless.

I think: mzz bootloader is wrong or different.
My bootloader works differently.

Nice. I really like how one person's 'complete pain in the butt' turns into someone else's 'quite easily'

Even without the PA, you can power up the boards (once you've got the reverse side built). The test code will verify that the RF chips are talking on the SPI bus properly.

I have a test dfu file here:
dl.dropboxusercontent.com/u/52854517/universaltx_DOA.dfu
The code is in the main deviation depo (under the universaltx dir)

I never actually finished the code to interface it with the radio, so at the moment it can't do much more than write out status on the stdout pin. I currently have PPM (JP2 pin 1) configured for stdout.

The stm32f072 has a built-in USB bootloader. To enable it, you should place a jumper across BOOT0. This jumper places the stm32 into bootloader mode when power is applied by USB (but not by normal 5V supply). If you plan to use a 5V supply to the 10-pin header, you can leave the jumper in place. The jumper is there so that the board can optionally be used as a USB controlled radio (maximizing its utility)

Just install the STM DFuSe tool:
www.st.com/web/en/catalog/tools/FM147/CL...C961/SS1533/PF257916

Then start the software, and plug in the board via USB (without 5V power attached). DFuSE should detect the board if everything goes smoothly. Then just 'Upgrade' the dfu file (make sure not to do an 'Upload' since that is actually a download and exactly the opposite of what you want)

JP2.1 is the debug output. Hook it up via a USB2UART at 115200,N,8,1
If everything goes really well, it will output:

Please send me an DEVO 12S bootloader, and how-to: How to reprogram the factory bootloader.

Thank you

hello PHR and Guys

i real want to build hardware TX devo 7e , but i read in '' README "" bitbucket.org/PhracturedBlue/deviation/s...fe/README?at=default

,there has

'''Building for ARM (on Linux) '''
Building for ARM (on Windows)

Builing the Windows binary on Linux
Building the Windows binary on Windows '''

and others problem , Path.....
I use windows and i will build for Window , right ? don't care to Linux ?

and loading firmware for arm, use a USB BOOTLOADER or a USBprogramer for ARM ?

any a guide by photo maybe it will clearly .

thanks

Is there anyway to extract the DFU bootloader from a working Devo 10 unit? Can I make use of this code? bitbucket.org/PhracturedBlue/deviation/s...tloader.c?at=default

Looks like there's no source for the DFU bootloader? Is there anyway to copy the DFU bootloader from a working unit?