Advanced Search

I think it's the way to go ( particularly getting rid of the walkera encryption for all the devos), this or the mcu change like PB did with his Devo7e 256k 'Ulitimate' . Nevertheless, I foresee the same issue in the future, while 4-6K is a big step it can't be compared to the gain of changing the mcu, I'm no programmer so I can't speculate on when the 7E will it the wall again.

I have a spare 7E that I could use, only if there is enough interest, and I can revert to the WK bootloader if this endeavor is not pursued.

In my investigations, I discovered that PB had already looked into this, and apparently decided not to do it. But that may have been before the port to the 7E, and certainly before the current space issues on it started.

I suspect we could recover 4-6K of space on the 7E by replacing the Walkera bootloader with our own. I think that's worth putting in the effort to create the bootloader (well, modify one I'm already working on for another project, anyway), but not if nobody is willing to make this mod.

So, how many of you are willing to flash a new bootloader on a 7E if it meant we would have breathing room for extra features again? Instructions can be found at www.deviationtx.com/forum/6-general-disc...-7e-bootloader#34250 .

More interesting, how many are willing to test such code for me, considering I don't have a 7E or interest in getting one? Before answering, you might verify that you can flash walkera's bootloader, which is available via the links section.

The other change that I''d probably do here is to remove Walkera's "encryption" code, so we could use standard dfu tools instead of having to use theirs. Given the lack of support from them, this is a must and PB is already moving in that direction but with their bootloader.

Richard96816 wrote: PB's post on re-flashing the Devo 7e boot loader will probably work with ST-Link. (Worked fine for my 7e.)

www.deviationtx.com/forum/6-general-disc...-7e-bootloader#34250

Just a warning in case it's not obvious: the devo boot loader has odd additions to it, so that it only works with the devo firmware (or PB's thing). So you may not want to use it as a boot loader on anything else.

On the other hand, I've been thinking about replacing the boot loader on one of my devo's so I can use the standard dfu to load files. Haven't gotten beyond just thinking about it, though.

PB's post on re-flashing the Devo 7e boot loader will probably work with ST-Link. (Worked fine for my 7e.)

www.deviationtx.com/forum/6-general-disc...-7e-bootloader#34250

The ST-Link is more powerful than the USB boot loader anyway, and not too expensive. So good enough. My 'generic board with yellow pins' does seem to have the USB ROM loader. When I enable Boot0 it shows up on USB, though my Linux box doesn't yet want to connect to it. There are posts of others successfully flashing them from Windows.

www.sunspot.co.uk/Projects/Arduino/STM32/STM32.html

As you say, there appear to be many paths to, and flavors of, boot loaders on the STM32s.

(I still have a suspicion that a 'bricked' Devo can be restored with a USB cable and a couple jumpers.)

Richard96816 wrote: Maybe I've been reading too many Chinglish manuals lately. But the various app-notes that I've read all seem to say the whole STM32F1 'series' currently includes the ROM USB bootloader. A few earlier date coded chips (not F103s) were apparently not supported. Some in the F1 series are singled out for working differently, but they all seem to include the bootloader. I think.

Guess I better unwrap some of the boards I've been receiving recently and try them ... I have wondered why the Devos all seem to have 'unnecessary' pinouts for STlink connections.

www.st.com/web/en/resource/technical/doc..._note/CD00167594.pdf

By my reading, they all have boot loaders, but exactly what the boot loader does depends on the µ-controller in question. The F103 chips only load via USART1. The F105 and F107 chips can load via USART1, USART2 and DFU.

AFAIK, the maple mini has a "user" button and BOOT0 isn't connected to anything. The maple boot loader (which is running from flash, not replacing the USART1 boot loader) checks for that to load to flash beyond it via DFU. The minimum system development board that I have is missing the user button, and instead has jumpers for BOOT0 and BOOT1. BOOT0 causes the chip to jump to the on-chip boot loader to load via USART1. Not sure how ST-LINK works in that - my st-link is still on the way. BOOT1 is supposed to make it load code to RAM instead of FLASH and run it, but I've not been able to get that to work. BOOT1 is also connected to an IO pin, so you get a user jumper instead of the button. I think I agree with the designer that the two boot jumpers is better for development than a user button.

Notes on the minimum system development board: check the forums at stm32duino.com - they have links to what little English information there is, including the canonical pin diagram. They also call them the "red pill" and "blue pill" boards, which I'm going to use 'cause it's easier to type. Finally, I've tweaked some of the libopencm3 examples to work on them; let me know if you're interested in them, but they are pretty straightforward - mostly moving the led pin to the right place.

mwm wrote:

Richard96816 wrote: Getting started with STM32 built-in USB DFU Bootloader

The first thing they say is "Check for eligible STM32 products supporting this function in table 1 of application note AN3156." That application note is at www.st.com/web/en/resource/technical/doc..._note/CD00264379.pdf

The STM32F103 - used on the "minimum system development board", the similar maple mini clones and the Devo Tx's - isn't listed in that table. You can go downscale to the STM32F0 or upscale to the STM32F105, STM31F105 or STM23F3 or STM32F4 (Cortex M-4's instead of M3's in the F1).

Maybe I've been reading too many Chinglish manuals lately. But the various app-notes that I've read all seem to say the whole STM32F1 'series' currently includes the ROM USB bootloader. A few earlier date coded chips (not F103s) were apparently not supported. Some in the F1 series are singled out for working differently, but they all seem to include the bootloader. I think.

Guess I better unwrap some of the boards I've been receiving recently and try them ... I have wondered why the Devos all seem to have 'unnecessary' pinouts for STlink connections.

www.st.com/web/en/resource/technical/doc..._note/CD00167594.pdf

Richard96816 wrote: Getting started with STM32 built-in USB DFU Bootloader

The first thing they say is "Check for eligible STM32 products supporting this function in table 1 of application note AN3156." That application note is at www.st.com/web/en/resource/technical/doc..._note/CD00264379.pdf

The STM32F103 - used on the "minimum system development board", the similar maple mini clones and the Devo Tx's - isn't listed in that table. You can go downscale to the STM32F0 or upscale to the STM32F105, STM31F105 or STM23F3 or STM32F4 (Cortex M-4's instead of M3's in the F1).

Getting started with STM32 built-in USB DFU Bootloader

I'm pretty sure the AVR (which is an Atmel thing) won't work with STM chips. Would have to kludge the wiring in any case.

It won't work with dfuse out of the box, or at least dfu-util doesn't see it as a dfu capable device. For that matter, it doesn't show up as a USB device at all. There are a number of dfu bootloaders available for that work like the Arduino stuff: they occupy the first ~2K of FLASH, you compile code for that offset address, and they'll load and start it. There's even one in the libopencm3 examples that works pretty much out of the box.

You sure you don't have some kind of USB<->Serial programmer? Those are needed for a lot of the older/smaller Arduinos. Worst comes to worst, you could use an Arduino script that echo'd bytes between the USB port serial line and a softserial instance.

Sounds like it's time to re-flash the bootloader ...

www.deviationtx.com/forum/6-general-disc...-7e-bootloader#34250

It should be possible to do without the stlink, but not sure how that's done with Devo.

Re-flashing brought mine back to life.

Cereal_Killer wrote:
Having said that I did just buy two, they look fun to play with, but I doubt they work with the arduinos IDE and, at least large scale, they're not cost compatible with the <$2 pro mini.

I see your point. A couple dollars can make a difference at times. Especially when you want to buy a few. Otherwise, 32-bitness for $5 seems like a winner. Oh, the things you could do! And I have seen them for less occasionally. Next year they will be cheaper ... Getting ahead of the curve might be nice.

Oh, and there is some support for the Arduino IDE. But folks here might appreciate the incentive to embrace the Deviation world a little more fully instead.

(I've not really worked with STM code or hardware yet. All my recent experience is with Arduino.)

Haven't tried the onboard ROM bootloader yet either. That's sounds like a winner! Wondering if that's accessible on Devo radios.

mwm wrote:
That board says "for arduino". Does that mean it's got an arduino-compatible bootloader, and you one of the Arduino board settings will work? Or something else entirely?

I'm pretty sure it needs an st-link for programming. I think arduino-compatible suggests you can use arduino shields and stuff ...


Edit: Apparently the STM32F series all have built-in USB bootloaders in ROM. St-link will work, but is more for debugging.

Richard96816 wrote: [Wondering if it's not time to change our focus on MCUs for small projects. Reduce the number of development environments necessary ...

Been wondering that myself. There are a bunch of 32-bit arduino wannabe's around. Most of them are aimed at the internet of everything, so include Wifi of some sort. Which I think might be a win for the things I'm doing.

But which of them do you want to invest in for the long term? Personally, I think what I'd like is a RPI or similar in a pro mini form factor.

That board says "for arduino". Does that mean it's got an arduino-compatible bootloader, and you one of the Arduino board settings will work? Or something else entirely?

Not too crazy

Someone has done tx conversation to another mcu. I put together stock core 7e using 0.96" oled (on youtube) there are few pics of oled in hubsun tx (this forum)
I had planned to mini guide core7e using the 256k mcu. And bonus PB done all the work changing code and bootloader.

7e is by far easiest to build, using just serial connection to screen. And second screen is on PB wish list or random thought
My idea was more about a simple way to upgrade old tx's. Most are better built than new stuff just needs kick ass software.

Now i have connection details Eagle all hardware but all boxed in storage and only mobile for tinternet. That said i could give you shopping list. Hardest thing to solder would be 8 pin soic. Rest is all ready done for most part. I did want minor mod to dev board so to run 1s but mostly just to use better switching supply.

Firmware in RX cannot be determined because only bootloader version is read by UP02 upgrade tool. You can try to activate telemetry in TX though - if it works, it's v1.1.

Have success

Sorry if I wasn't clear. You will continue to work with ini files on the 7e. you will upload and download ini files to the tx. The uploader app will convert from the ini to the binary format and back for you in the background. So you won't lose any functionality, but you will be forced to use the DeviationUploader Java App to upload to the Tx (instead of Walkera's Dfuse tool).
The Uploader shows you the file system so you can copy files to and from the tx like you do today using USB. The interface is a little different, and it is a lot slower (due to how the bootloader works), but again, it should have parity functionality to what you have now.

As for using an Android, it is already planned, but will require the UniversalTx with bluetooth dongle. I'm not sure that functiality will ever make it to the 7e either. If your Android phone can act as USB master, it is probably possible to port the Deviation Uploader to it, but that is beyond my scope.

The USB converter's port won't show up on arduino until you actually plug it in and restart the software.
You don't click burn bootloader, you click on the arrow icon ("Compile and upload").

As for using a sim, unless you absolutely need to use the dongle for DRM purposes, you can simply set the protocol to USB-HID and the devo 7e will work over the USB port as a standard game controller.

The parts I ordered have all shipped so I'm potentially a couple of weeks away from turning the soldering iron and having a go

Have downloaded the Arduino for Windows software and have run it and set the following
Board: "Arduino Pro or Pro Mini"
Processor "ATmega 328 5V 16mhz"

Can't go much further till I get the TTL programmer in I guess?
(I only have the option of com1 port)

Not a clue what to set the Programmer to - maybe the TTL USB wont show in the list of options till its plugged in?

I guess once this is done I copy and paste the code you have kindly shared into the textbox and click "burn bootloader" and it will do its stuff?

I have done another wiring diagram - can someone please confirm it looks correct ?



Sorry about all the newbie questions that may seem very obvious to the more experienced, but this is new ground for me

Also - last question for tonight I promise!
I do currently use the TX on a sim (Phoenix mainly) religiously every night for 15 mins at least
Will I have to have a switch to break the connection to the arduino (power or the PPM to TX) for when I use it on the sim or will it do no harm staying powered up and inline?
(my phoenix.ini on the TX will not use the pots if this makes any difference - eg will not be using PPM in and PPM out simultaneously)

Regards
Rob

If you cannot get into the bootloader (i.e. unplug battery, turn off switch, plug battery, hold down EXT while turning on), then your transmitter needs to be replaced. you need to send it back to your vendor. I assume the battery is charged? obviously a low-battery may cause the transmitter to behave erratically

PhracturedBlue wrote: In the links section on the left. there is now a link to all of the bootloaders I have (including the devo7e_256 variant). I also added all of the legacy firmware files I have since Walkera is making it difficult to locate them these days

Cool! thank you.