Advanced Search

The bootloader patch would be pretty safe if every time the dfu runs it ensures it finishes with a valid bootloader installed. Even if it has to completely program the original bootloader due to some error. There'd still be a risk if there was some hard bit error that wasn't an issue before trying to write to the bootloader area. Definitely would want an st-link for doing the development

While a patched bootloader would be incompatible with Walkera dfuse, it's the Jumper owners who benefit from the patch so pointing them to deviationuploader might not be an issue. Walkera owners would have no reason to patch their bootloader and could keep using dfuse if desired.

However the people willing to patch their bootloader are probably people who would always burn the right firmware anyway. Maybe suggesting to Jumper to change the bootloaders would give the biggest benefit.

But what keeps us from making deviationuploader the preferred flashing tool?

Have you had any bad experience with flashing devos? So far the only problems I see arising in this forum are filesystem related. Also, only a successful upload of our patching dfu would actually trigger bootloader patching within the device after a reset.

hexfet wrote: Haven't looked at the bootloader at all. Would it be possible to modify by running special code on the tx? A dfu to be run one time?

I think it should be veryfeasible using a one time dfu, as dumping the bootloader is very simple and I don't expect write protection (see dump_bootloader.c), and libopencm3 has write flash routines. But what would indeed be a safe end user process for this?

I don't know how the walkera tool will react to a different ID...

Maybe I'll try this on the t8sg... Worst thing that could happen is hooking up the st link and reflashing the original bootloader.

What identifier you want to change? DEVO-7E? Then DfuSe can't be used to flash firmware, it can flash known transmitters only.

Also, rewriting the bootloader by transmitter is dangerous. What you will do if any problem happened in time flashing the bootloader?

Without a unique identifier not much can be done. If Jumper will change the bootloader then we can support in the future.

Haven't looked at the bootloader at all. Would it be possible to modify by running special code on the tx? A dfu to be run one time?

Well, I also thought if we could modify deviation to rewrite bytes in the boot loader to correct identification in Jumpers, but any user interaction like "selecting your deviation device" when boot loader is a 256k one identifying as DEVO-7E would still require the display to work, as we cannot overwrite/modify the bootloader from DeviationUploader Any other ideas?

As the bootloader won‘t let us read arbitrary flash pages, the count fix is the way to go. But don‘t you think we should at least change the display of the recognized device? Devo7e is just plain wrong, and why not at least fix this for DeviationUploader, which should become the preferred (and also cross-platform) flashing tool?

At any case bootloader has "DEVO-7E" as identifier and DfuSe also display "DEVO-7E" for "Devo7e-256/T8SG/T8SG V2 Plus/IR8M".

Pull request placed.

Yes you're right, count has to be 122 with 12k bootloader in devo7e and its variants.
I'll try to modify the uploader to read out the changed bootloader bytes to automatically switch to the 256 settings if applicable, as that would be the most foolproof. Haven't done any Java in 15 years, so please be patient

I think "count" has to be 122 (122*2K = 244K), size without bootloader (16K). Devo8 "count" = 120.

Recently I have undertook some steps to port DeviaitonTX to STM32F0 platform - so it can be used on FlySky I6X (possibly on I6s).
As base I have taken target devo7e - because of similar flash size - should I try with some other target?

FlySky devices have no flash memory so filesytem idea can not be applied. Using I2C EEPROM for storing settings - seems to be just fine.
Removing ini handling will give us some additional space

By removing USB support and file system It seems to be just fine to store fonts and images in MCU flash.
In I6X there is additional bootloader taking 16kB of the flash - after dumping this space can be used for data/code as well.

However I see few issues:
-used libopencm3 is not up to date - tuts GPIO/RCC handling requires lot of processor definitions.
-AFHDS2 protocol is incomplete - I was working on disassembly
-I6s has no EEPROM so MCU flash must be used for emulation.

Is there anything more that I should consider?

Always good to be efficient....

FYI, in my devo U7E I soldered the 512k chip version (STM32F103RET6) (512kb Flash/64kb SRAM) it works fine and is full pin compatible it is not much more expensive, but I beleive the bootloader only adress and use 256k.
No idea what is in the jumpers and iranges......

Customised bootloader
Customised devo 7e (128k) Deviationtx

Hello! Can You share your code? I want to run deviation on maple mini and use hp4067 (16 ch multiplextor) for extra pins.
But now i have problems with bootloader - standart bootloader from devo7e seems to be not working on maple mini. And I can't find sources of bootloader.

That's why I ask - Can you see anything on the screen with firmware update mode?

If it is LCD with devo7e contrast scaling, we have to see bootloader screen.

The first photo of this topic is completely the same I can see with empty T8SG USB drive. If I press ENT I can see scrollbar at the right.

vlad_vy wrote: It's last batch T8SG. I think it related to low battery voltage. User tells he use 4xAA battery. Probably LCD low voltage lower contrast and we can see the bootloader screen instead of black screen.

Vlad, the 4xAA is the problem. I believe the last batch T8SGs are still using the same stacked 5v and 3.3v linear regulator architecture. If so, users cannot use 4xAA (nominal 4.8-5.0 volts). The 3.3v regulator is almost certainly far below regulation - and that can easily be checked. Unfortunately some vendors still advertise the T8SG as 2S LiPo or 4xAA capable which can create confusion for customers. The Jumper box and recent Bangood descriptions no longer claim 4xAA compatibility. As I recall, a month or so ago when we were coming to grips understanding that the first batch regulators were dropping out of regulation with battery just below 7volts, there was a user reporting similar start-up screen behavior.

It's last batch T8SG. I think it related to low battery voltage. User tells he use 4xAA battery. Probably LCD low voltage lower contrast and we can see the bootloader screen instead of black screen.

Most likely it means Devo 7E bootloader - early stages of development, forgot to remove the picture.

Thanks for that information Hexfet. I see where I can adjust the Freq-Fine option but not select format options. I suppose that this will only be available after I flash the nightly build though?

This is the module I fitted into the Devo

I appreciate your help and also when I put the 7E into programming mode, it is not showing up in available devices in the Dfuse tool. It shows up as STM bootloader in Windows 7 device manager but that's another problem that I need to sort out so I can flash the nightly build

What about using this LED to let the user know that the bootloader has been entered? Perhaps something like fast blinking?

Once I get my Tx, I can probably tweak the existing bootloader to enable the screen. We'd need to flip it too which will be more complicated I think. Replacing the Walkera text with something better should be possible too. Or we could just completely replace the bootloader with an open-source one. I think there is value in being able to know that your Tx turned on and is in the bootloader.