Advanced Search

I'm working on linux, so for now I will be using SWD. It is also much faster, so easier for debugging.
But yeah if I want the original firmware back, I really need the original bootloader or a similar one with the same encoding. So that's why I want the original bootloader. I can maybe lent another devo F7 and extract it from that one, but if someone else has it already or could extract it for me that would be nice!

Sorry for the late response, but my devo F7 was broken and needed to replace the STM. It is now working again, and also replaced the flash memory(4MB now).

I don't have the devo F7 bootloader yet, so I'm not capable of flashing the device with DFU. I'm now flashing with SWD, so in my repository this is changed. So make sure you change it back to DFU before flashing(else you will also lose your bootloader).
Btw. if anyone could get the original bootloader out of the device that would be nice

To try and see my work in progress:
github.com/tudelft/deviation

This is what currently is working:
- Capable of setting up the USB
- All normal system functions seem to work, like battery warning etc.
- Made some basic LCD functionality to write text at a certain position.
- Made the flash screen, the USB screen and also a part of the main screen.
- Also made a part of the menu by showing the menu title.

What needs to be done:
- Getting the rest of the menu to work
- Finish the rest of the character map
- Maybe replacing some of the characters would be nice (don't need chinese characters)
- Finding out how to make some special text (like big font etc.)
- Maybe get rid of some of the unneeded GUI structure, but I'm not that into deviation so I'm not sure how to implement this the best way.
......

Can you get into the bootloader (press EXIT while power on) and the Deviation file system (Press ENT while power on)?

If so I suggest reload the latest nightly build and its files system.

Otherwise if you can at least get into the Bootloader you can use Defuse to reload the original Devo Firmware and LIB.

(Hopefully the Walker Site is back up soon - See
www.deviationtx.com/forum/3-feedback-que...wnload-updater#16405

1. We don't touch the bootloader, so even a bad dfu can't harm the tx, you can always go back to the original or an other version...

2. There is a section in the downloads called nightly build, which always contains the latest build:
www.deviationtx.com/repository/Deviation...ases/Nightly-Builds/
I hope it answers your PM too...

3. The DfuSe v2.0 will be fine.

Good morning...

I bought a new Devo8S radio and I have few question. I want upgrade my radio to "Deviation" software.

1. I compiled new version of Deviation TX (3.1) and I have a dfu file and filesystem. What if I upgrade my Devo with wrong file ( I don't know if my self build version is good.)?? Bootloader is upgrading, too??

2. Who have a latest Deviation TX (3.1) and can send me a tested version (build 8a12e1d from bitbucket.org/PhracturedBlue/deviation ) ??

3. I read a User manual and there is a instruction how install a deviation tx.
There is a link to Devention DfuSe USB Upgrade Tool 1.7. This version not working on my WINDOWS 7 x64. Only working DfuSe USB Upgrade Tool v2. Can I upgrade Deviation TX (3.1) with this v2 tool??

Sorry for my English....

Spent a night trying to elicit response from System Memory bootloader on Devo7E - no success at all.

Theoretically, you just need to connect BOOT0 to VDD - there is a conveniently broken out header inside of Devo - 2-pin 100 mil between plated holes - just between SWD header and RF module.

Only downside to this is that its windows only.
Now had a thought about that.

OpenBTL does have other ways it can work, update from flash. Deviation has USB built in all ready and not OS dependent. So what if we could use that instead. And with other Devo Tx's there so much more flash free so make boot area larger if needed and run it so we have option to load different Dev builds and go back to release build at will. Rename 'Protocol' folder to reflect Build number or keep folder for stock setup plus Dev folder. Maybe it could even be away round 7e limited space, remove options as needed but go back when needed.

Now I don't know if this is even doable but I see in Deviation code that bootloader can be deleted. Could deviation be used to replace loader so no need to open Tx or need any extra hardware.
But would mean no going back to Stock Walkera which I know would be a shame.

Oh I wouldn't be able to do any of that Hey I'm shocked I got this far.

For serial port you don't need an extra bootloader - they have one in system memory and you need only to set BOOT pins accordingly.

You must have programmed your own hook function, that's the only needed part. It should take much less than 11MB, I'd be surprised if it's 11KB, so you can attach it here.

No need to post the all tree source, only the relevant changed files.

Did you use the VM to compile the bootloader to ?

Walkera uses a modified version of the official STM32 bootloader. It used to be easily available on the stm32 downloads page, but I can't find it anymore.

It is the OpenBLT bootloader.

feaser.com/openblt/doku.php?id=homepage

It isn't the same as walkera (but who knows, maybe they used this one...)it just a way to convert old transmitters to devention.

I'll be converting a Wk-2602, with one of these boards, they have a stm32F103VET6 so I could load Devo10 (maybe the devo8 with a patch for the 2 pots that the 2602 has) firmware.

dx.com/p/stm32-core103v-cortex-m3-stm32f...lopment-board-150550

dx.com/p/port103v-stm32f103vet6-arm-cort...nt-core-board-148526

dx.com/p/stm32-mcu-arm-cortex-m3-stm32f1...lopment-board-150993

How large is this bootloader? And can you provide us with the source?

I thought I already had one for the telemetry, but I guess not. It is certainly a reasonable request.
There isn't a lot more stuff that can be added as a module. we are limited by the size of a module (currently 4096 bytes). Making the module bigger cuts into available RAM, and we have some that are very close to max-sized already.
Since we can't unload a module (your model would fall out of the sky) you can't really modularize anything other than the protocols.

Another option would be to replace the bootloader.
It may be possible to get up to 2kb back if we used a smaller bootloader, though I'm not sure it is possible to enable USB in so little code. You would definitely lose the display during programming, and it would be pretty risky (since a program failure would result in a bricked Tx). Anyhow, the Devo7e is probably getting pretty close to the end of its development range. I'm just not sure how to squeeze much more out of it.

We could also remove the standard GUI which would save quite a bit of space, but I'm sure a lot of folks still use it. Not really my preferred solution. I don't think it helps much to remove the advanced GUI, since the standard one uses quite a bit more ROM than the advanced if I recall, so having a 'standard' build and an 'advanced' build is probably not going to help much.

It looks interesting but not for me until I deleted the bootloader of one on my tx...

I took a very short look in the code trying to help you understand the way ports are used (and changed). It is obvious that they are controlled by a few registers like GPIOA->CRL, GPIOB->CRH, ..->BRR and ..->BSRR, but I have not found the correct *.h-file where those names are defined.
Usually the registers are organized in bits where bit0 represents the GPIO-line 0 of the corresponding port (GPIOB bit3 = PB3).
Because the loader is constructed for many MCUs it has an abstraction layer what makes it easy to program (because names are equal for every MCU) but without the translation table (usually a MCU-NAME.h-header-file containing a lot of #define-directives) I can not tell you which of the registers GPIOn->XXX is used for what purpose.

If you point me to the header file I could tell you more.

What's wrong with the standard Devo bootloader?

All STM32F10* have serial 'Bootloaders' but DFU loader is not standard. Walkera have done there own 'DFU Loader'. All(nearly) dev boards do have usb serial on board but I know you have your arduino hardware so what ever you'll be ok.

Just be nice to USB to update code as well as loading file system. My work around does work. I did wonder if code could be shifted to run from 0x08000000 but more going on than i understand

There are opensource DFU loader as i said just written in a way that makes me want to jam a pencil in my eyes LOL

Crap didn't think about the loader.


But I was under the impression that :

- when you compile deviation code you should not use the python script that encodes the DFU

- then upload the newly created DFU to the MCU using usb/serial converter, ST Flash_Loader_Demonstrator and own ST bootloader present in the MCU.

Doesn't the board, you showed me, contains a usb/serial converter ?

Doesn't all ST ARM MCU contains a bootloader ?

So why the need for an open-source bootloader ?

Sorry for all these questions, I'm a little confused.

Well I only needed to build module for my FG and confident that will be fine. Only thing I would 'like' that i can use Futaba's 12 channel PPM.

Hubsan TX is an accident to be honest, welcome one Wouldn't even have done it if i hadn't broken my LCD i was going to use for RF module. OLED does look right in that space and for Fg module perfect.
I'm going to re used PCB in TX. Got a7105 + amp and have some old low power cypress module that i maybe able to use. And I'll get to use Midelic for RX so winner all round if you ask me.

The code I have no Idea with I just fluke getting oled running its NOT Arduino!! PB written so much that you only needed to join the dot's. PB did start to 8S upgrade longtime ago and TFT with touch screen are only $8/9 each.

Only things out standing or untested:
DFU loader : Now i found opensource one but as above No idea how to change it. Why i say this is because I can flash my devo 7e with no loader using STLink v2 steps >erase>flash @ 0x08000000>then flash again without erasing>@ 0x08003000> and that does work but you have do that every time there's a change to code. Which is fine for me but I never managed to do that using usb/serial ie ST's bootloader but if I download the whole flash. I can use that with usb/serial.
The power down circuit PB has posted that info here but I plan to use momentary switch. No idea how that will effect things.

Well I broke my walkera loader...bugger. Well I have it running fine less loader. I can flash code using STLink to 0x8000000 doing that will not work so flash again @ 0x8003000 without erasing flash. Then i go to Target/MCU core and click 'Reset' that shows running. Disconnect and power TX as normal and will boot up fine.
Now using ST built in bootloader and usb serial i can not do as above. I can download whole flash area and upload that and works fine but unless you have STlink you ain't going to able to do that.

So is it possible to compile code so it runs from 0x08000000 with minor changes ?

This i noticed but no idea if its anything to worry about.
bitbucket.org/PhracturedBlue/deviation/s...o7e/crc.c?at=default

deviation / src / target / devo7e / crc.c
all other devo's 6/8/10/12 it's thisshould it be changed ?

Yes I shall do write up on updating TX without Walkera loader, using STlinkv2 and ST serial bootloader. Results are little odd but all appears to work OK.

Well i have a Q: about how to compile Deviation Nightly Builds ?

I made minor change to make file so i could compile using 'make target=devo7e' which works fine, no problems there.
Still to re-flash using ST's serial bootloader i need Bin file that i 128k in size and loads @ 0x08000000. Though code needed to run start's @ 0x08003000.
Using STlink I can use Bin file that make spits out but using ST serial bootloader I have to use a full 128k bin otherwise it don't work.
Can make file be simply changes to do this?