Advanced Search

I can't get this idea out of my head ...and being that I am not that experienced...but am familiar with which end of the soldering iron gets hot, I have so many questions I need to answer but unable to self serve as far as finding answers

IF I were to get a discovery board....(Have found them at less than £30, which I can afford, BUT I can't think of any other good reason why I would need one other than for this project)

Would the process be similar to
Flash the Walkera bootloader (the one for the ultimate 7e 256)
Flash it with deviation from either the 7e ultimate (or Devo 10?)
Wire the hardware up (Gimbals/pots/switches/RF boards)

Or will I need to get a special Bootloader and compile/roll my own Deviation for it?
Thinking about it deeper - would the screen even work without me writing my own code?

Assuming I have not incredibly over simplified this (a likely scenario)
How tolerant of potentiometer values is this going to be?
(will the hardware need "conditioning" in any way or maybe being quite specific values)
.....eg could I join the queue on hype train central and get some hall effect gimbals


Cereal Killer - Hows that board coming along?
Could be the best solution to my quest (and I'll buy 3 if they are ready )

Regards
Rob

If you are a programming expert, you might go with Q X7, but with Deviation on a Devo10 every thing will be much more easy to set up.
The structured menue is more convenient than pressing twice or long pressing a button.....

The technic of the new Taranis is nice but the build quallity of the case and the gimbales are not.The screws are terrible to use.
Set my throttle stick from selfcenter to no center and I was afraid to break something.

Besides this, OpenTX 2.2 is not ready and so Companion can not be used to it´s full features.
Flashing firmware and updating the SDCard is ok, but you have to use the radio for every model setup. If you missed something,you have to exit and start from page one again, no simple page back.....
I was used to do all with EXT and ENT at power on with my Devo but now I have to set the QX7 into Bootloader mode before plugging into USB.
For easy accessing the SDcard as massstorage I could use a different firmware module but then the USBHID device is lost.

Think twice....


Edit: As for the multiprotocol module, the STM32 version seems to exiist as a DIY project only and the Atmel version can not hold all avilable protocols due to less ram. You must select what you want and compile......

Here is the potential wiring to make the DSC (trainer port, PPM) work for two-way comm. I didn't actually have a way to test, since it requires different port handling in Deviation.

I can not find the 2 pins to be "jump" on devo10 and the power pins ?
Do i have to jump those on devo10?

for the 10pin st-link the connections are
be sure not to use the 5V line as it will damage the mcu.

[edit]
silpstream has a great tutorial on his site for flashing the bootloader >> silpstream.com/103/ultimate7e-flashing-the-bootloader/
[/edit]

PhracturedBlue wrote: It turns out I had to do this today, so I can be pretty specific.
1st you need an stlink-v2 and a copy of the devo7e bootloader

You'll be using the 20pin header on the stlink.
on the 7e board, there is a 5-pin unpopulated header below the MCU, one pin is labeled RESET. We;ll call this pin '1'
connect pin1 (reset) on the Tx to pin 15 (NRST) on the stlink
connect pin2 (tms) on the Tx to pin 7 (TMS) on the stlink
connect pin3 (tck) on the Tx to pin 9 (TCK) on the stlink
connect pin4 (GND) on the Tx to pin 20 (GND) on the stlink
connect pin5 (Vdd) on the Tx to pin 1 (Vcc) on the stlink

just above the 5-pin header is a 2-pin unpopulated header. this is BOOT0. you need to place a jumper between the 2 pins.
On the upper left of the 7e circuit board is another 2-pin unpopulated header. This is power bypass. You'll need to short these together too, but not yet.

You need to install the software for the stlink-v2 to your PC (Windows only)

Now, plug in the st-link to the PC. It should be detected and drivers installed
Startthe ST-Link software.

make sure there are batteries in the Devo7e, and apply the jumper across the power bypass.

Now press the connect button in the stlink software on the PC. It should connect. If you get an error message, you have a connection wrong somewhere.

You will need to do a bulk-erase of the chip 1st. then you can load the bootloader and do a program&verify.
your bootloader is now loaded.

You need to disconnect the jumper on BOOT0 and power bypass before you do anything else.

I have ST-link V2 usb which has 10 pins only,
I can not find the pin connection using this to flash bootloader.
don;t want to kill the TX again...
anyone has the pin connections ?

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

Would you let me know the link of how to use ST-link to reflash my bootloader tx ?

You can try to reflash the bootloader.
It is available on our Google drive:
www.deviationtx.com/downloads-new/catego...nsmitter-bootloaders

You need an ST-LINK compatible programmer for that, which you can obtain from ebay for less then $3:
www.ebay.com/itm/ST-Link-V2-Programming-...e:g:8soAAOSwZVlXiICF

vlad_vy wrote: What is Dfuse Demo v3.0.5??? Can it damage bootloader?

Winner winner chicken dinner. DfUse demo v3.0.x is the official ST tool, NOT the walkera specific version we use with the needed obscurification code.

Edit FDR beat me to it!

Oops! That's the ST Demo software.
While it probably won't demage the bootloader (if the address was right), it doesn't do the Walkera encrypting, so the FW won't work with that...

What is Dfuse Demo v3.0.5??? Can it damage bootloader?

Sorry for the unrelated post but when I did the ultimate 7e mod and flashed the bootloader I didn't short the boot pins and everything worked fine as far as I remember. Any reasons as to how or why this happened ?
Thanks for everything everyone !

i'd make sure that all of the pins have a good connection and that there aren't any shorts first before thinking anything else bud, as being able to flash the bootloader only requires 4 pins to be connected properly, and that doesn't confirm a sucessful mcu replacement, I speak from experience lol

It seems nobody is intend to answer a question which is not "new". I also asked some questions - and after some hours (more than 10) of reading and searching in threads with 100 and more replies i found my answer

Deviation is a great work for me - and i am using this since one year. Only the forum is sometimes a little unsorted and many thread are starting with one question und then changed to 10 and more the question. It's hard to find out if you want to know anything special.

Maybee the programm team of Deviation has a lot to do with development - and less time for the forum.

I have read anywhere that the Difference of the F12E version A und B is the bootloader of Walkera - so the output is regulated by software - And Deviation opens the output power from 10 to 100 mW of the CRY6939 Transiever modul.

(My CC2500 modul shows me an output power of 300 mW with Deviation)


Sometimes a thread is ending "i have it" - but with no word about the solution.

First be sure your batteries are fresh. If they are run down you won't get good results. Also, it's good practice to safely eject the USB device every time you're ready to disconnect.

Can you tell us if you get the program screen when you press EXT while turning on the power? If that's the case, the bootloader is still working correctly and it's mostly a matter of getting Windows to talk to the Devo. If you are getting the program screen, connect it to your PC and listen for the USB notes -- if the device is recognized it should make a sound. You should then be able to see the device in Device Manager. What is the exact name in Device Manager? It normally shows up under USB Devices: on Windows 10, my Devo 6S says "STM32 DFU". If this is working right, DFUse should see your Devo (I find version 2.31 to be the most reliable with my three Devos). If it isn't working right then it's likely you've got the wrong driver for the programming mode. Please confirm that the Devo is ok with that part.

If not, try uninstalling all of your DFUse software. Then reboot. Then try to install DFUse 2.31.

The part you mentioned as failing is the USB Drive. Press the ENT button while turning on the Devo -- do you get the USB screen? Power off, connect to the PC USB, then power back on holding the ENT button. You should hear the USB notes on the PC. Look in Device Manager to see what driver is in use. On my windows 10 device It shows as a Disk Drive, but i think it sometimes shows as a USB controller or device. if you cannot find the driver or the driver is wrong, then you need to correct it.

There are a number of tools to fix an incorrect USB driver, such as Zadig and USBDEView, but I find them tricky to use. So let us know what your PC thinks it is talking to.

Nitro_123 wrote: I think it shouldn't have 7e in the nqme at all like victzh has suggested
U256 takes my vote

but 2 of mine are 384k and one 512k so u256 would be wrong, plus there's only 244k memory available due to pb's bootloader hack so 256 is way wrong


































o/j u256 is a good option

Ok,
So I replaced the MCU and flashed the bootloader. That all seemed to go well. Now I connect batteries and turn on unit and nothing happens so I can't connect to defuse tool to load firmware. Any suggestions. It appears that a pin isn't soldered well or something.

@mdmbc, sure, but it needs another, fifth round of review - one footprint is hard to solder manually and 3.3v power supply is routed to apparently busy pin - IRQ. It is not used in any of existing Devos (I still need to check Devo 12S which I have and Devo 12E which is coming this Friday), but marked, so we better move to another unused pin. It is probably harmless, but anyway.

@Arnold - 6S, 8S, 12S should just work, I can test on 12S myself, I don't have 6 and 8. F is more stubborn for some reason, and it's complicated by my inability so far to dump the bootloader - to debug it properly I need to erase MCU to unprotect it and thus need to dump bootloader first to restore it. I'm working on it, but it is still not there.

I think cereal_killer posted that configuration is working for him...however...

Due to unplanned ground interactions my main quad ended up on the bench. I decided to upgrade and do a little testing. It had been running great on cleanflight 1.9.0 for a year or so. It has a naze rev5 (F1). Also made the same tests on a bare board of the same revision. i installed the latest cleanflight configurator (1.2.4), and then...

• Configurator only supports cleanflight version 1.13.0 and greater so must upgrade
• Bootloader not recognized. Must short bootp pins to force firmware to flash. This is required every time even after successfully flashing cleanflight 1.14.1
• Enabled frsky telemetry on default port (uart1). Cleanflight stops working as soon as armed. Usually see a 0x5e out the telemetry port right before the lockup. Board will not respond until powered off and on.
• Enabled frsky telemetry on softserial1 (pin 6). Telemetry data appears on pin 6. Set telemetry_inversion=on and d4rii recognizes and sends telemetry, but screen updates are irregular.
• On bare board put frsky telemetry on hardware uart2. The telemetry_inversion setting has no effect so d4rII doesn't see valid data.
• tried cleanflight 1.13.0 (oldest version supported by the configurator). Same results.
• tried betaflight 3.0.1. Same results.

At this point I flashed back to cleanflight 1.14.1, put frsky telemetry on softserial 1, and started comparing the data out of cleanflight to the data received at the tx. Cleanflight does send a time update every 5 seconds, voltage every second, and others at 500ms and 125ms intervals.

About once a second all these timers align and cleanflight sends about 20 telemetry packets in about 100ms! Each packet is 4 bytes so that's around 800 bytes/s. Over the air telemetry packets are sent at 36ms intervals with 10 bytes of hub data. However the d4rii generally sends 8 packets containing hub telemetry followed by 6 containing only RSSI and analog voltages. That's 80 bytes every 504ms for a max over the air hub telemetry data rate of 160bytes/s. Add the fact that the d4rii likes to send every serial packet five times over the air and I begin to suspect this may be a problem.

The GPS time update from cleanflight every 5 seconds is always at the end of one of these large packet streams which may explain why it's rarely received at the radio. My theory is that the d4rii is dropping telemetry packets it doesn't have time to send or space to buffer.

The hub telemetry emulator code I used for testing avoids sending a bunch of telemetry at once by skipping the high frequency updates whenever a low frequency one occurs (e.g. if it sends a time update it skips sending voltages till the next scheduled update). And on deviation the screen updates as expected when receiving from the hub emulator.

I tried building cleanflight v1.14.1 from source so I could test this theory but get an "out of flash memory" error :/ Anyone had any success building it on Ubuntu 16.04? I agree it seems like this telemetry configuration would be in use by many people so I'd really like to test a modified cleanflight to verify if this is the problem.