LibrePilot Forum
General Category => General Discussion => Topic started by: TheOtherCliff on October 24, 2015, 11:25:10 pm
-
Update 2016 May 24:
Executive Summary: (Linux) Add TauLabs or dRonin udev rules to allow unprivileged users to access the new Sparky2 USB ID. This post has a bu_sparky2.opfw attached. Flash this (and run it a few seconds) with your new version LP GCS (next or 16.06 release) just before you start using the new version of LP. If you are running an older version of LP Sparky2 code, do not flash the new bootloader updater (BU) until you have a new version (GCS and firmware) to use it with.
Instructions for adding the needed udev rules to Linux:
- Download the attached file named 45-uav.rules
- Run a shell / terminal / command prompt and change directories to where ever you downloaded the file
- enter the following commands
sudo cp 45-uav.rules /etc/udev/rules.d/45-uav.rules
sudo udevadm control --reload-rulesThis assumes you are a member of the Linux plugdev permissions group. If you have problems, refer to this page:
https://github.com/TauLabs/TauLabs/wiki/Development-Linux-setup
The latest Sparky2 code has been changed to have a bootloader that is compatible with the TauLabs bootloader that comes on new Sparky2 boards. This Sparky2 code is not in next yet. This new compatible bootloader means that you do not need to do SBL procedure to get a new Sparky2 board working with LP code. Assuming you have a Sparky2 board with the default TauLabs bootloader that it came with, when this new LP code is released, you will just flash the new LP bootloader updater (bu_sparky2.opfw) using the rescue function of the new LP GCS. It is important to run the BU for a few seconds after flashing (just press Boot). After that, use the rescue function of the new LP GCS to flash the new normal firmware (fw_sparky2.opfw) that came with the new GCS.
For those who already flashed the old, incompatible BL onto their Sparky2 boards, there is a way to avoid doing the SBL procedure again. Don't do this until you have access to the new GCS and firmware.
Do this to avoid doing SBL again on your Sparky2:
- You can uninstall old LP GCS, but it is a good idea to export your settings before you upgrade anything.
- Build or download the new LP sparky2 GCS and firmware (in next right now, soon to be released).
- (Linux) Add new udev rules for the new Sparky2 USB ID (old Sparky2 USB ID was same as Revo).
- Disconnect flight battery power and only use USB for this procedure.
- Leave USB unplugged until instructed to plug it in.
- Use the bu_sparky2.opfw that is attached to this post. It has the new, TL compatible USB IDs.
- Use your new LP GCS. Go to the Firmware tab and press Rescue, then immediately plug Sparky2 into USB.
- After a few seconds, the Open button will appear. Press Open, navigate to and select the bu_sparky2.opfw that you downloaded.
- Ignore the warning about board b01 doesn't match firmware 9201
- Press Flash and wait for the erase and flash to complete.
- When flashing is complete, press Boot to boot the BU. Let it run for 10 seconds.
- Unplug USB from Sparky2.
- Press Rescue again, then immediately plug Sparky2 into USB.
- It should select the correct firmware, or press the Open button, navigate to and select the correct firmware fw_sparky2.opfw
- Press Flash and wait for the erase and flash to complete.
- DONE
- If you can't find fw_sparky2.opfw because you are running the final release, you can do the following:
- Once bu_sparky2.opfw has been flashed and run, you could disconnect USB and then press the Upgrade or Erase-and-Upgrade button (follow the instructions on screen) to install the firmware that comes with the install.
<End of Update 2016 May 24>
Understand that there are two software levels of being bricked besides bad hardware:
- You have a current, working LP/OP bootloader on your board. You know the bootloader (current or LP/OP or not) is working if the blue LED comes on and does some kind of blinking, whether that is: blinks once every 7 seconds, fast blinking, or fade from bright to dim to bright every couple seconds. You know that bootloader is a current LP/OP version if you can start an Emergency Rescue Procedure successfully. If you have a current, working LP/OP bootloader you do not need to do the SBL procedure (which is a pain to do).
- If the blue LED does not come on or stays solid (no blink or fade bright dim) for more than say 15 seconds, or if you can't successfully start the Emergency Rescue Procedure, then you need to use the SBL procedure to put at least a current LP bootloader on it.
CC3D: First of all, you need to know that cloners call everything CC3D to get you to look at it. A "Revo" is a Revo and has nothing to do with CC3D. The CC3D SBL procedure cannot be done with USB. Your computer must effectively have a serial port (usually a USB to "ttl level" serial adapter) and the correct cable. That usually means an "FTDI" USB to serial adapter or similar. You can use another OP board like Revo or CC3D with USB VCP Function set to ComBridge 57600. If you have an OP board and a standard 4 pin MainPort / FlexiPort cable, you don't have to make a cable.
If you have a current working LP/OP bootloader on your board already, you can skip over the SBL instructions and just do the "Emergency Rescue Procedure" with the firmware you want to flash.
SBL procdures:
I have not tested this as I don't have a Windows box handy.
The attached dfu-util.exe is one I found on the Internet. Please scan it for viruses to be safe.
Please post back here if you don't see any posts that say it worked and there were no viruses.
I built the attached bootloaders.
If you have a different bootloader on your board then, before you can even flash it, you need to write the bootloader.
This is the case if you:
- had CleanFlight on your board.
- just bought a new Sparky2 board.
- tried TauLabs on your Revo board.
- etc.
To write a bootloader you must use SBL (System Boot Loader) which is always there and can't be erased.
To use SBL the two tiny tiny tiny SBL pads on the board must be shorted before and during power on.
Sparky2: SBL is located on top side of board close to LEDs and baro chip.
Revo: SBL is located on bottom side of board close to largest black chip.
CC3D: SBL is located on top side of board close to corner hole close to ESC/servo outputs (use 3.3v and SBL).
They must be shorted together at least from a little before to a little after connecting power. Probably the easiest way is to temporarily solder a blob to connect them. You can leave the blob on until you are done with the flashing command and must remove it after that.
Personally, I do it this way though. SBL pads must be shorted at the time that power is applied (when plugging in USB). First, you need a little mound of solder on each pad (but not shorted together). My new Sparky2 was the first board that had bare copper there and needed solder mounds added. Second you need a very small "safety pin", the type with a small coil at the bottom. Leave pin closed, and if you want, you can carefully spread the coil a tiny amount with a knife. Finally, to use it... Assume mounds are left and right, hold pin vertically with coil down and so that one coil is in front of both mounds and one coil is behind both mounds. When done correctly, it tends to self-center and stay in contact when you hold it. Voilà! If you have three hands, you can hold the safety pin to the SBL pads while you are plugging USB in.
If you did SBL correctly, then only the green LED will be on. If you have more colors than that, you did something wrong or the SBL pads were not shorted together during the moment of power on.
Be aware that upper/lower case is important in Linux / OSX commands.
Open a command prompt. "Terminal" in Linux. Command prompt (cmd.exe or command.com) in Windows.
You need to know where you downloaded the files. The easiest way to flash this is to start by going to the directory where the downloaded files are stored:
cd whereever-the-files-are-stored
If you can successfully flash firmware, but it won't boot and run, then flashing and running the resurrection firmware is usually necessary:
This is because for a Revo or Sparky2 that has run TauLabs firmware, there is another hoop to jump through. After flashing the bootloader, and before flashing the real firmware, you must flash (and run for a few seconds) a resurrection firmware that clears a special place in the settings. This is not always necessary, and may be related to which TL version you used. LP/OP uses this area for logging, and fails to start up if it is corrupt. Use the following instructions to flash the bootloader first, then the resurrection firmware, then run the resurrection firmware till it finally finishes iniitialization (30 seconds) then (using the normal update and erase procedure) the real firmware that comes "built into the GCS" with standard releases.
Do this to use SBL to flash a bootloader via USB for Revo or Sparky2:
In the following, whateverfile.bin is something like bl_revolution.bin
Short SBL and plug the board into USB and type:
dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -D whateverfile.bin -s 0x08000000
It takes a minute or two if you are using an entire flash image like e.g. ef_revolution.bin, but for the smaller bootloader files (e.g. bl_revolution.bin) it is just a few seconds.
You should see it say some technical stuff, then start printing dots (old version of dfu-util does not print dots, even a large file should finish within 10 minutes and come back to the command prompt). When it is done, unplug USB and unsolder the solder blob.
Emergency Rescue Procedure:
Flash and run the resurrection firmware:
- Run the GCS
- Unplug the board from power and USB.
- Go to the firmware tab in the GCS and press the Rescue button.
- Plug the board into USB.
- GCS recognizes the board in a few seconds.
- Press the "Open" button to navigate to and select the correct resurrection firmware opfw file that you downloaded.
- Press the Flash button to write the currently built firmware.
- It will start in a few seconds. First it will erase, then it will write (flash) the firmware.
- When the flash is done, press the Boot button which will cause the resurrection firmware to run
- Let it run for 30 seconds at least. On Sparky2, I see blue and green LEDs for 10 seconds, then just green for another 10 seconds, then the board boots normally (LEDs do the normal operation colors). You might also see just 20 seconds of green followed by normal operation LEDs.
Flash the normal flight firmware:
- Run the GCS
- Unplug the board from power and USB.
- Go to the firmware tab in the GCS and press the Rescue button.
- Plug the board into USB.
- GCS recognizes it in a few seconds and selects the correct firmware for you.
- Verify that the firmware is for the correct board.
- Press the Flash button to write the currently built firmware.
- It will start in a few seconds. First it will erase, then it will write (flash) the firmware.
Be aware that some versions of flashing tools don't print anything and bl files are small and thus fast to flash, but ef files are big and if the flasher looks locked up, you should give it 15 minutes and it will finish.
Edit: 2015 Dec 18
Added tested resurrection firmware for Sparky2 (removed old version) and greatly clarified the instructions. I got a TL Sparky2 firmware that consistently bricked my LP Sparky2 firmware so I could finally code a proper fix.
Edit 2016 Jan 10
Clarification that a Revo is a Revo and has nothing to do with CC3D.
Edit 2016 Jan 19
Added a Revo 1509 firmware with resurrection.
fw_revolution_resurrect2-1509.opfw
Edit 2016 Jan 22
Added Nano
bl_revonano.bin
ef_revonano_resurrect2_1509.bin
fw_revonano_resurrect2_1509.opfw
Edit 2016 Feb 13
Edited instructions a bit to make it clear when SBL Procedure can be skipped.
Edit 2016 May 24
Put an update about the new Sparky2 USB IDs at the top of the page.
Edit 2016 May 27
Instructions for adding udev rules to allow access for new Sparky2 USB ID
Edit 2016 May 28
Attached final release version (?) of bu_sparky2.opfw that can run on either the old (0b01) or new (9201) device ID.
-
There is also a more short story if you have a build environment setup and a Linux box :
Simply type :
make ef_revolution_dfu
You can also use the dfu-util from host :
make DFUUTIL_DIR=/usr ef_revolution_dfu(This call /usr/bin/dfu-util installed in your host)
I'm pretty sure this can be done the same in windows with the right path to dfu-util binary
-
That's some good shortcuts for new devs etc. :)
I started to write about that in another thread, then realized that most users will have a Windows box or at least access to a Windows box.
The current instructions are good for Revo and Sparky2, but I need to write up the serial port stm32flash version for CC3D users that have something else on their CC3D.
-
Thanks for this, I had flashed raceflight on my revo, and wanted to go back to OP/librepilot, but it wouldn't boot properly. Simply flashed your resurrect firmware using GCS, and it works now. Thanks a million.
-
To write a bootloader onto a CC3D:
- You can't replace a corrupt bootloader on CC/3D using USB. You must short the CC/3D SBL pins together and use serial (e.g. USB to serial adapter, sometimes called an FTDI) to Mainport (or Flexiport?).
- this assumes you are using a Windows PC
- I found the stm32flash.exe on the Internet. I don't have a Windows box handy and I can't vouch for it so you should scan it for viruses before using it. Here is where I got it: https://github.com/stko/oobd/blob/master/tools/stm32flash/stm32flash.exe but it is also attached to this post.
- download the attached files into a directory of your choice (Desktop is fine if you know where it is located on the hard drive)
- connect a USB to serial converter (commonly called an FTDI for the brand of the chip) to mainport (or flexiport?). You will need to make an adapter cable. You need 4 wires: ground to ground, +5V to +5V, TxData to RxData, RxData to TxData
- determine which COMport the USB to serial converter is using. Temporarily plug the USB to serial converter into the PC. Look in ControlPanel -> System -> DeviceManager (or read the notes at the bottom of this post)
- Unplug the USB to serial converter from the PC. Connect the CC3D to the USB to serial converter, short the SBL pads on the CC3D together (as described in the first post), then plug the USB to serial converter into the PC
- run the following command from the directory where you downloaded stm32flash.exe and bl_coptercontrol.hex
stm32flash -w bl_coptercontrol.hex -g 0x0 COMwhatevernumberyourcomportis
- unsolder the SBL pads
- make sure that power and USB are unplugged from the CC3D and press GCS -> Firmware -> Rescue
- quickly plug the CC3D into the USB port
- wait a little while for the Upgrade button to become active
- press the Upgrade (or Upgrade & Erase) button and read the information and wait for it to finish
Please post if you use this and tell me if it works.
Supposedly this command will list the Windows Comports:
wmic path Win32_SerialPort
The Arduino UNO can act as a USB to serial converter if you follow some instructions.
http://blog.oscarliang.net/use-arduino-as-usb-serial-adapter-converter/
and this will tell you which comport is connected to an Arduino device:
for /f "usebackq" %%B in (`wmic path Win32_SerialPort Where "Caption LIKE '%%Arduino%%'" Get DeviceID ^| FIND "COM"`) do set comport=%%B
echo Com Port for Arudino device is detected as %comport%.
ef_coptercontrol_1609.bin is the Entire Flash for Librepilot 16.09 on CC/3D. That is it contains bootloader and normal (application) flash. If you flash this you don't need to flash anything else to run 16.09.
ef_coptercontrol.bin is the Entire Flash for Librepilot 15.09 on CC/3D. That is it contains bootloader and normal (application) flash. If you flash this you don't need to flash anything else to run 15.09.
Edit 2015 Dec 18:
I added a CC/3D resurrect firmware in case anyone runs across a coptercontrol that has been bricked by running TL etc. firmware. Note that this is not a problem with the TL etc. firmware, but that LP sees what appears to be corrupted storage to it just because the TL firmware has been run. The ef bin file can be flashed with stm32flash just like a bootloader. The fw opfw file can be flashed from GCS if you have a working bootloader (start with CC3D unplugged and press Rescue then plug in CC3D. Open and select the downloaded resurrect opfw file. Flash.
Edit 2020 Oct 4:
Here is the archive.org copy of an old web page that uses the STM Flash Loader Demo program to write a CC3D bootloader:
https://web.archive.org/web/20190701124058/http://www.southquay3d.com/index.php?route=news/article&news_id=9
-
i'll do this tonight, I need to get cleanflight off a cc3d so I can dump LP onto it.
-
done!
I did mine a bit different tho, I use the GUi from ST. Flash Loader Demonstrator http://www.st.com/web/en/catalog/tools/PF257525
solder the sbl pads
connect ftdi minus the VCC
connect external battery pack to servo pins to fire up cc3d
load the app, find my com port erase the chip then load up the new .bin disconnect everything, unsolder the sbl bridge and done.
took pix along the way if anyone wants images.
doing this was pretty easy. I flashed cleanflight onto the board the same way previously.
-
Do this to use USB for Revo or Sparky2:
In the following, whateverfile.bin is something like bl_revolution.bin
Short SBL and plug the board into USB and type:
dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -D whateverfile.bin -s 0x08000000
It takes a minute or two if you are using an entire flash image like e.g. ef_revolution.bin, but for the smaller bootloader files (e.g. bl_revolution.bin) it is very quick.
You should see it say some technical stuff, then start printing dots for a few minutes. When it is done, unplug USB and unsolder the solder blob, then run the GCS.
If you flashed the EF (entire flash) file which includes both bootloader and firmware you are done flashing.
If you only flashed a bootloader, you still need to use GCS to flash the firmware.
Do the following to flash the firmware:
- Unplug the board from power and USB.
- Go to the firmware tab in the GCS and press the Rescue button.
- Plug the board into USB.
- GCS recognizes it in a few seconds and selects the correct firmware for you.
- Verify that the firmware is for the correct board.
- Press the Flash button to write the currently built firmware.
- It will start in a few seconds. First it will erase, then it will write (flash) the firmware.
Any idea how this resurrection firmware works?! I just finished building another board managed to get the df until thing to flash the bl to the brand-new chip... the revo took the resurrection firmware in GCS but fails to completely update to the latest firmware.. its like its stuck in a boot loop. I remember having this issue before. I just can't remember what the order in doing this is to stop the boot looping from happening.
-
Boot loop, about 7 seconds per cycle, blue LED on and a quick blip is the symptom of bricked Revo that requires the resurrection firmware. You do the Rescue procedure, starting with Revo unplugged and pressing the Rescue button and then plugging Revo in. Flash resurrection, boot it and let it run a few seconds. Flash normal firmware.
blue LED fading dim to bright to dim is a different thing. You may not even have firmware on it in that case. Do the same resurrection procedure, but just use normal firmware (the Update button once you have started Rescue).
-
Thanks you, I flashed taulabs as well and board was getting in boot loop. I tried everything. but Simply flashed your resurrect firmware using GCS, and it works now. Thanks a lot :D ;D ;D
-
To the first post I added working resurrection firmware for Sparky2. I finally got a TL firmware that consistently bricked my LP Sparky2 firmware and took the time to code a proper fix.
To the CC/3D post, I added resurrection firmware for CC/3D if anyone ever gets a bricked CC/3D.
-
flachskopp answered my request (german language branch) for help regarding Revo boot problems and after following the c/pasted instruction of yours I finally managed to get my Revo clone to boot at least twice in a row. Thank you for your great work. I already spent 10+ hours to get my clone to boot at all! Now my real question: can I use the resurrection fw to fly? When I flash the LP fw after your resurrection fw the fc does not boot, with yours it does!
LP says this is a shared/LP-72_sparky+-dirty fw though I definitely downloaded the Revo res. fw 2 and 2-1. Currently I do run the 2 version (215KB). Does it matter?
And my GPS still is not recognised or listed in GCS - GPS is assigned to MainPort (7N with twisted TX/RX wires, green solid and blue blinking LED).
Again thanks!
gunslinger
-
I was working on a branch that made unbricking for both Sparky2 and Revo. That is just the name of the branch. If "revo" is part of the file name, it is the correct firmware for Revo.
Flash the resurrection firmware. Boot it up and let it run for 60 seconds. After that, you should be able to put any other firmware on it. These firmwares have fixed many bricked Revos. If there is more than one FW for your FC, you might try the other FW.
-
Thanks for your reply. I am still struggling with my Revo clone to make the GPS work. I tried the following:
resurrecting the fc - check
upgrading & erasing to fw provided by LP - fails to boot afterward. Only rescue & safe boot works. No normal boot with the fw and my board.
resurrecting with res-fw2-1: boots but no sensors reported to LP GCS though it is stated with the red sign as a correct fw.
resurrecting with res-fw2: boots and sensors are reported but reported with an exclamation mark (I do ignore this), so far the only working option for me. The last thing I would like to achieve is to get the NEO-7N GPS to communicate to the Revo.
System GPSPositionSensor claims:
Status NoGPS
SensorType Unknown
AutoConfigStatus DISABLED
BaudRate Unknown
Actually the GPS is connected to the MainPort declared as GPS with 57600bd and UBX protocol.
Is there any way to force the Revo to recognize the GPS?
Thanks for your help
Michi
-
It sounds like there is a hardware problem if only the resurrect firmware will run.
Can you save any settings (then power off and back on and settings stay set) using resurrect firmware? I ask because this is all about reformatting the same storage that holds settings.
Analogy: If your computer hard drive gets corrupted data, you can reformat the hard drive, write correct data back out, and it will work again, but if the hard drive is broken, reformatting will not help and nothing can be saved to hard drive and seen after reboot.
-
Yes, using your firmware allows me to boot regular, store parameters like used ports for GPS and disabling of telemetry. Also the board levelling is stored. My manually modified System/GPSPositionSensor values stay written too. I might soon try to fly with it in a tricopter where a CC3D is working well for a hardware test. My main aim was to use the Revo for FPVing - at least I will try if it works at all. Claiming a defective fc will be of no use since other members already stated how difficult/impossible this will become with this vendor. Maybe I have to find a different seller for a working Revo clone...
Can you propose a different firmware I could try?
Michi
-
I added fw_revolution_resurrect2-1509.opfw to the first post.
-
So I have a CC3D that I wanted to flash. It has Copter Control and Rev. C on it. See below for what I get attempting to flash through the main port using FTDI adapter. Any help would be appreciated.
stm32flash -w bl_coptercontrol.hex -g 0x0 COM5
stm32flash - http://stm32flash.googlecode.com/
Using Parser : Intel HEX
Serial Config: 57600 8E1
read_byte: No error
Assertion failed: 0, file stm32.c, line 92
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
-
that assert comes from trying to read the serial port and getting an error.
Did you do the SBL stuff? You must.
-
Yes, I did the SBL short if that is what you meant
-
Try using the Flash Loader demo from ST.
http://www.southquay3d.com/index.php?route=news/article&news_id=9
-
Did that one too but no luck. That was how I started before attempting the command line methodology.
See my post here: http://www.rcgroups.com/forums/showpost.php?p=33751801&postcount=6428
-
So its a board issue, not software...
Any blinking led while powering ?
Did you check voltage on SBL pads ? (3.3v on one pad, without solder join)
-
Because the pads were bridged using solder blob to put it in DFU mode, the light turns solid once USB is plugged in. The power on the 3.3v pad when I measured it before bridging was 3.3 V. I am beginning to believe it is a hardware error also as I've attempted all permutations and combinations to get this done. I've never had any issues flashing other boards like APM, NAZE32, 3DR radio, Pixhawk, satellites and hosts of OSD's.
-
What did you flash on it previously ?
If you remove the SBL solder join, still some life with one led blinking ?
If no response using SBL and no blinking led at all you should consider a 15$ board going to trash...
-
Did try the additional fw posted... I assume it is identical to the distributed 15.09 fw - either way it did not work. Only fw allowing me to boot repeatedly is your resurrection fw. Therefore I think you are right and the board is faulty. Very sad considering the money, time and brainpower spent to make this clear. Thank you for your help. I appreciate this very much and might try a Revo board from HK - at least one person posted it to work... I will follow this thread anyway in case other members show up and post similar requests or come up with a solution.
Thanks again!
Michi
-
I've loaded Openpilot, Librepilot, BaseFlight, CleanFlight aand BetaPilot into the board before. I can have it back to any of them once I remove the bridge, run Openpilot and rescue.
I just wanted to remove the openpilot BL and flash a new BL into the board.
-
Did try the additional fw posted... I assume it is identical to the distributed 15.09 fw - either way it did not work. Only fw allowing me to boot repeatedly is your resurrection fw. Therefore I think you are right and the board is faulty. Very sad considering the money, time and brainpower spent to make this clear. Thank you for your help. I appreciate this very much and might try a Revo board from HK - at least one person posted it to work... I will follow this thread anyway in case other members show up and post similar requests or come up with a solution.
Thanks again!
Michi
That is very strange. It does sound like a hardware issue at this point. Which firmware does work?
Here is a 1509 with resurrection with watchdog turned off. It may work for your possibly broken hardware. Let me know.
-
I've loaded Openpilot, Librepilot, BaseFlight, CleanFlight aand BetaPilot into the board before. I can have it back to any of them once I remove the bridge, run Openpilot and rescue.
I just wanted to remove the openpilot BL and flash a new BL into the board.
There is no changes from OP BL to LP BL.
You should be able to update BL without any SBL soldering stuff.
Just rescue and flash Bu_coptercontrol.opfw
Rescue still works ?
https://librepilot.atlassian.net/wiki/display/LPDOC/Firmware+Tab#FirmwareTab-UpdateBootloaderandUpdatefirmware
-
@TheOtherCliff
Thanks again - I definitely will try this one and report what happens.
Michi
-
Actually even the paralyzed watchdog is keen enough to refuse the board to boot - I have to replace this fc with a proper working one. Tried your modified watchdog fw thrice - no booting except after rescue and safe boot. So your resurrection firmware remains as the one and only bootable one. If you are interested I can send the Revo to by post. For me it is useless since I got 2 working CC3Ds and want a PosHold capable controller.
Thanks for your efforts.
Michi
-
so which firmware was it that runs?
-
I just discovered something tonight after assembling another revo and fixing a member from RCGroup's dead revo. If the resurrection FW doesn't work its the 16MB SPI flash chip on the rear side thats the problem... As soon as I swapped that out with a known working one the board lives..
As a matter of fact not one of the flash chips that I've received from Digikey seem to work properly from the OP Revo BOM Spreadsheet. I usually end up using a clone's flash chip instead. Its like I can't get them to cooperate with the board.
Is there another way to get these chips to work outside of the GCS update procedure and that DFU util program?!
-
One and only firmware working with my strangely behaving Revo is the fw_revolution_resurrect2.opwf (size 221KB). With this fw the board boots up alone and the parameters I changed seem to stay saved.
Michi
-
There is no changes from OP BL to LP BL.
You should be able to update BL without any SBL soldering stuff.
Just rescue and flash Bu_coptercontrol.opfw
Rescue still works ?
https://librepilot.atlassian.net/wiki/display/LPDOC/Firmware+Tab#FirmwareTab-UpdateBootloaderandUpdatefirmware
Yes Rescue still works and I can use BU anytime. My objective is to check if I could flash a .hex file into the board. If I am not mistaken, the .hex file should be a combination of new BL and firmware.
I currently have LP flashed and functional in the card.
-
Witch hex file are you talking ?
-
Witch hex file are you talking ?
It is a .hex file released by BetaFlight. I wanted to use it for my ER250 because of better PID and other tuning.
-
Better ask support in Betaflight forum, if i remember at some point cleanflight used the same bootloader so the switch OP/LP to cleanflight was easy.
Don't know if changed.
-
Looks like OP bootloader is not supported anymore by Cleanflight, since https://github.com/cleanflight/cleanflight/releases/tag/v1.11.0
If you are able to flash cleanflight using a Ftdi, you can return to LP bootloader flashing a bl_cc3d.bin or a ef_coptercontrol.bin. See download page on Wiki.
-
Looks like OP bootloader is not supported anymore by Cleanflight, since https://github.com/cleanflight/cleanflight/releases/tag/v1.11.0
If you are able to flash cleanflight using a Ftdi, you can return to LP bootloader flashing a bl_cc3d.bin or a ef_coptercontrol.bin. See download page on Wiki.
LOL....thanks for your help.
-
Will this work with Nano as well?
-
For ? Flash ?
-
Unbricking a Nano, I have solid green light no matter what I do. I tried to flash and saw this
~/Downloads/all_fw1509/bl_revonano sudo st-flash write bl_revonano.bin 0x8000000
2016-01-21T22:59:44 INFO src/stlink-usb.c: -- exit_dfu_mode
2016-01-21T22:59:44 INFO src/stlink-common.c: Loading device parameters....
2016-01-21T22:59:44 INFO src/stlink-common.c: Device connected is: F4 device (low power) - stm32f411re, id 0x10006431
2016-01-21T22:59:44 INFO src/stlink-common.c: SRAM size: 0x20000 bytes (128 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 16384 bytes
2016-01-21T22:59:44 INFO src/stlink-common.c: Attempting to write 32768 (0x8000) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erasedEraseFlash - Sector:0x1 Size:0x4000
Flash page at addr: 0x08004000 erased
2016-01-21T22:59:45 INFO src/stlink-common.c: Finished erasing 2 pages of 16384 (0x4000) bytes
2016-01-21T22:59:45 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-01-21T22:59:45 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2016-01-21T22:59:53 ERROR src/stlink-common.c: flash loader run error
2016-01-21T22:59:53 ERROR src/stlink-common.c: run_flash_loader(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
-
dfu-util + sbl pads
see first post
-
Automatic unbricking is currently scheduled to be part of next release (release is getting really big :) ).
@gunslinger I am confused. the resurrect 15.09 that I built for you is supposed to have the same resurrect code that fw_revolution_resurrect2.opfw has
When you come from some other brand of firmware, you will need to do SBL procedure and flash either bl_xxx.bin (bl is raw bootloader, then you must do emergency rescue procedure to add firmware) or ef_xxx.bin (entire flash, means bootloader and firmware). This is required, unless you know that the brand you came from has a bootloader that is compatible with LP/OP. I hear that the one brand that had compatible bootloader does not have it any more, so you always must use SBL procedure to switch brands.
@viperz28 I have never run across a bricked nano, but it seems possible if you enable flight side logging. FYI if you leave SBL shorted out, you will have just green. SBL must be unsoldered after the procedure. I recommend that you try SBL with ef_revonano_resurrect2_1509.bin (I attached some nano firmwares to the first post). Be aware that some versions of flashing tools don't print anything and bl files are small and thus fast to flash, but ef files are big and if the flasher looks locked up, you should give it 15 minutes and it will finish.
-
I think I will try the ef option and go for SBL procedure. This will have to wait until monday since I do not own a FTDI myself. I will post the result as soon as I tried it.
Michi
-
You know, you may be on to something. It may have an old bootloader on it?
-
To replace the bootloader, the easy way is usual "emergency" (unplug, press rescue button, plug it in) rescue procedure, but flash the bu_revolution.opfw file. That doesn't require that you do the SBL hassle. After that, you will have to use emergency rescue procedure to flash the normal firmware.
-
Since my board goes into bootmode, the bootloader itself seems to work - but... as you stated, I assume that the existing bl might be not 100% compatible to OP/LP and therefore the upgrade process fails. I already tried the bootloader update/upgrade process and this is not working. The bootloader update does its job, but after flashing the regular firmware my Revo just boots in safe mode (already mentioned a while ago). Still only your one resurrection fw leads to repeated standard booting. Since I got not much to loose regarding this special fc I will go again for your proposition and try the bu several times.
In case there still is no progress I think I will do it the hard way with trial and error until I get the board into flash mode by shortening the pads and go for the SBL thing. I simply refuse to admit that I bought trash with no practical use ;) I hope you are not annoyed by my posts.
Thank you for your repeated support - very much appeciated!
Michi
Edit: Just ordered a FTDI device. If I'm lucky it will arrive on tuesday. Will keep you updated if this brings me forward.
-
Looks like OP bootloader is not supported anymore by Cleanflight, since https://github.com/cleanflight/cleanflight/releases/tag/v1.11.0
If you are able to flash cleanflight using a Ftdi, you can return to LP bootloader flashing a bl_cc3d.bin or a ef_coptercontrol.bin. See download page on Wiki.
LOL....thanks for your help.
Just a quick update. I just received a new board and was able to flash it. It was definitely related issue that prevented my first board from flashing.
Thanks for all the help!!
Best Regards
-
Just got my FTDI today - prepared hard- and software for tomorrow's operation!
Michi
-
Of course I tried Raceflight on my OP Revo (no clone) and of course I got stuck on Raceflight (which was not a big problem at that time).
I tried flashing the latest LP bootlaoder but the problem remained...
LOL and while I was lurking around for something new on LP forums I found this post by coincidence. This totally unbricked my Revo. I just flashed "fw_revolution_resurrect2-1.opfw" to my hardware via USB/GCS and I also installed the latest LP firmware to the board. Everything is back to normal. :)
Thank you very much.
-
First attempt to flash the Revo with my FTDI was a success. The rest more or less a failure. The standard LP fw simply refuses to work on my board. Both standard resurrection firmwares do let my board boot. But GPS still is not recognised. Neither the Neo7N nor the Ublox 6 I own (it definitely works on my multiwii pro board). All standard firmwares state my board running while connecting to the PC - no status display only log report. Resurrection firmwares first state bootloader, then running and show system status. I definitely think this board is crappy regarding GPS functionality. I will at least try to fly it.
Michi
-
I bought Sparky2.0 Clone from Banggood and tried to flash with OP. It was successful.
After couple of flashing, led always solid green and no blue led blinking at all. In addition to this, when I connected Sparky2.0 to PC, PC didn't recognize it.
Can i recover it with unbricking bootloader?
Thanks in advance.
-
A simple question here: does GPS functionalty only kicks in when a RX is installed and adjusted? I did not connect a receiver to the Revo clone yet...
Michi
-
First attempt to flash the Revo with my FTDI was a success. The rest more or less a failure. The standard LP fw simply refuses to work on my board. Both standard resurrection firmwares do let my board boot. But GPS still is not recognised. Neither the Neo7N nor the Ublox 6 I own (it definitely works on my multiwii pro board). All standard firmwares state my board running while connecting to the PC - no status display only log report. Resurrection firmwares first state bootloader, then running and show system status. I definitely think this board is crappy regarding GPS functionality. I will at least try to fly it.
Michi
Did you try fw_revolution_resurrect2-1509.opfw from the resurrect thread? I coded that to be exactly 15.09 but with resurrect built in. If resurrect firmware runs on your Revo board, then this should run and is 15.09 so you can use it?
One other thing. A friend bought a Revo clone and the mainport was bad but flexiport worked. It turned out that mainport had tiny tiny solder short (could only see with jeweler's loupe). I removed short and now it works well. Try the other port to see if GPS works on it. You should be able to erase settings, set Hardware page to say which port the GPS is on, save it. Plug GPS into that port, power off and on and see that GPS is recognized in system health (anything but red X is good). I assume that you have a Ublox GPS, and made a cable for it. Also, one common thing is that user makes cable with Rx and Tx backwards. You might try swapping pins 3 and 4 in GPS cable (carefully lift tiny tiny plastic flap in connector only far enough to slide pin out). Does GPS have an LED that comes on so you know it has power? Some only have an LED that comes on when it has a good fix.
-
Actually I think I left out the special *resurrect2-1509.opfw wit the latest attempts. I also tried connecting the GPS to the Flexiport with no success, repeatedly swapping the RX/TX wires. I will have a closer look on the board and look for solder shorts. The Neo7 GPS that came with the Revo does get a 3D fix when powered and I just got a confirmation for the Neo7: it works well on my new SP Racing board!
Thanks for your help!
Michi
-
Update: I tried the special *resurrect2-1509.opfw on my board. No success. Only both standard resurrection fw's are working. Still no GPS functionality. I tried to setup the Revo clone for normal flight operation by starting the vehicle setup wizard. I was able to perform the adjustments but the final save operation of LibrePilot software failed repeatedly (defective memory?). Also I do not get any RC input on PPM, will try PWM now and see what happens next.
Michi
-
My Revo Nano is bricked .The only light that is lit is solid green when connected to the USB.I can't get it to connect with the GCS,won't recognize the board.
Iv'e tried deleting and re-installing the drivers.Does anyone know how to resolve this issue.Thank You !
-
I bricked my Revo Nano, and my PC and GSC does not recognize it.There is only 1 solid green light when connected to the USB .
No other light lit.Does anyone know how to fix this problem.If I short the SBL pins the Device Manager shows an STMbootloader in the list.
-
I bricked my Revo Nano, and my PC and GSC does not recognize it.There is only 1 solid green light when connected to the USB .
No other light lit.Does anyone know how to fix this problem.If I short the SBL pins the Device Manager shows an STMbootloader in the list.
There is a thread about this
https://forum.librepilot.org/index.php?topic=208.0
but in short
dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -D fw_revonano.bin -s 0x08000000
Though please read thread before doing anything.
-
Do i put this string in at the command prompt while the SBL is shorted.This is new to me.
-
Do i put this string in at the command prompt while the SBL is shorted.This is new to me.
Yes, but read the thread ! ;)
-
I've read the thread on unbricking a and still can't get the board to flash.In device manager it says" STM Device in DFU mode".How do I get the bin file to flash onto the board.I am using the SBL pins .This is the only way to get it to show up in the device manager.As soon as I unplug the USB it disappears from the Device Manager and will not show up again until I short the SBL pins again.I have tried to flash while in this mode ,with no success.Is there something special I need to do.I have several other flight controllers on different quads and have never had this problem.This is a OP original Revo Nano .I can't use the rescue function in the GCS because it doesn't see the Nano.I am confused as to how to use the command prompt to flash the board.Any help will be very much appreciated.
-
There are a couple levels of being bricked. Short of a hardware failure, yours is the most bricked and requires SBL to fix it.
(Since you don't even have a blue light at all, your bootloader isn't even running.)
You must write either a bare bootloader or an "entire flash" that has bootloader and firmware. Either way, the file you will flash ends in ".bin" not ".opfw"
Don't use GCS. You must use dfu-util from the command prompt with the full dfu-util command documented there and here. Especially with the EF it will take several minutes to flash. Some versions of dfu-util just sit there till they are done. Don't interrupt it unless it has been 10 minutes or more.
With either bare bootloader or ef, after flashing, remove the SBL solder jumper. Power up the board. The blue LED should do something. If not, you have a hardware issue. :(
Now you use the GCS on the firmware page. If you flashed the bare bootloader you will need to do "emergency rescue procedure" (read first post in thread) to flash the firmware. If you flashed the ef, you can do any of:
- Update
- Update and Erase
- Halt then Flash
-
What will it look like in the command prompt if it is working correctely.My bin file is in my F drive under downloads.Not sure how to set up the command promt to flash the Nano.Never needed to do this before.I attached a file.
-
It looks like you didn't download the dfu-util from the first post in the other thread that Mateusz referred you to. It's the first one of the attachments to the first post in that thread. Or you don't have it in your path (usually works on windows if it's in the same directory you're in).
-
SBL is soldered.I do not even know what to type in the Command Prompt.I have downloaded the dfu-util.exe and ran it.
Still can't get it to flash.I have attached the prompt file .Thanks for all your help.
-
The last one you typed that didn't find a dfu device looks correct.
I don't have a nano so I can't check myself but in the windows device manager right click on the "STM Device in DFU mode", select properties, and find the usb vendor id and product id. If it's not 0483 and DF11 try the last command you typed but substitute the vendor:product id you find. And if it is different please post the numbers here.
-
All fixed (what a relief ).After reading your very helpful replies,I started looking at my drivers in the Device Manager.Somehow I had loaded an STMelectronics driver onto the USB Composite Device in the Device Manager.This is why it could not see my flight controller.After replacing the Driver from a list on my PC I tried the command prompt again and the board flashed in a matter of seconds ,See Attachment.I then followed (TheOtherCliff's ) rescue procedure and it worked flawlessly.Thank you for all of your help,I very much appreciate you guys and the LibrePilot/OP community and all your hard work.
-
This worked for me, Thank you!!!!
-
I have a bricked Revolution board... I have downloaded the bl_revolution.bin and the DFU-util file and placed them in a directory. I did the sbu on the board and it is giving me a solid green LED.
I ran this command line from the command prompt
c:\>dfu-util.exe -d 0483:df11 -c 1 -i 0 -a 0 -D bl_revolution.bin -s 0x08000000
and when I run it... I get this response
"No DFU Capable USB device available"
I am suspecting that I might need an FTDI interface to attach via USB ?
I'm a raw noob on this stuff.... :)
thanks in advance
Joe
-
I have a bricked Revolution board... I have downloaded the bl_revolution.bin and the DFU-util file and placed them in a directory. I did the sbu on the board and it is giving me a solid green LED.
I ran this command line from the command prompt
c:\>dfu-util.exe -d 0483:df11 -c 1 -i 0 -a 0 -D bl_revolution.bin -s 0x08000000
and when I run it... I get this response
"No DFU Capable USB device available"
I am suspecting that I might need an FTDI interface to attach via USB ?
I'm a raw noob on this stuff.... :)
thanks in advance
Joe
I am exactly the same as this, also when mine powers on now, regardless of BL pins being shorted, all i get is a sold green light and nothing else. Anyone got an answer?
-
I have a bricked Revolution board... I have downloaded the bl_revolution.bin and the DFU-util file and placed them in a directory. I did the sbu on the board and it is giving me a solid green LED.
I ran this command line from the command prompt
c:\>dfu-util.exe -d 0483:df11 -c 1 -i 0 -a 0 -D bl_revolution.bin -s 0x08000000
and when I run it... I get this response
"No DFU Capable USB device available"
I am suspecting that I might need an FTDI interface to attach via USB ?
I'm a raw noob on this stuff.... :)
thanks in advance
Joe
I am exactly the same as this, also when mine powers on now, regardless of BL pins being shorted, all i get is a sold green light and nothing else. Anyone got an answer?
I had about the same situation with my Revo. What worked for me was to short the pins, and follow the Emergency Rescue Procedure using the fw_revolution_resurrect2-1.opfw firmware.
-
Hello,
Does anyone have a good picture of where the SBL pads arte located on the Revolution Board?
Thanks in advance.
-
Here is
(https://forum.librepilot.org/index.php?action=dlattach;topic=208.0;attach=2397)
-
Laurent,
Like always thanks for your reply.
Is one of the pads a 3.3 v, or is that reference to pin on the chip?
-
The pad 3.3 is next to is 3.3 volts. People often use it to supply power to external sat receivers that need a 3.3 volt power supply. To go into BL mode just short the two pins.
-
Hwh, you mean to short the 3.3 volts and the other pad?
-
Yes, if you want to go into bootloader mode you short the two pins together and then apply power. After you're done flashing the bootloader you power down and remove the short.
The 3.3 pin is connected to the 3.3 volt supply and the other pin is connected to the BOOT0 pin on the CPU chip. It's normally pulled low by a resistor which enables normal operation. Connecting it to 3.3 volts pulls it high and enables the bootloader.
-
I was asking just to be prepared for the worst.
But I followed the wiki to recover and it worked like a charm.
https://librepilot.atlassian.net/wiki/display/LPDOC/Firmware+Tab#FirmwareTab-UpdateBootloaderandUpdatefirmware
Thanks for all the help to hwh and Laurent.
;D ;D ;D ;D ;D ;D ;D ;D ;D ;D
-
Hello The other cliff, I see you have a very clear idea of the separation hardware software, maybe you could help me as you did many times!
I basically started experiencing a problem with my oplink binding. making the story short. I unbuild the quad, cheked the revo and say that the antenna might have been broken. also I guess I had a PMM cable short on the TX side.
basically I remade it all, tested with the default settings 38.. 0-250 flex ppm also on the revo side set it PPm only, but the board will not bind. after going all around trying many things flashing again etc etc, I might get it binding with the standard channels , but as soon as I wanna change the settings for example to ppm only, channels 40-100 on both RX and TX, binding will either not happen at all or the signal bar will get full and empty full and empty, like fluctuating, not making the binding.
_ question, how can I 100 per cent sure, zero clean delete all infos on my revo ( oplink embed) and oplink T, to make sure I exclude a sofware problem?
_ How can I identify through the LIbre Pilot CGS which of the sides is failing on the binding process?
_ is there a simple way to test if the oplink was damaged by the antenna rupture? I mean could you point out some components I could test?
Thanks a lot
-
Updated May 28:
Repeated from first post. (Linux) Add TauLabs or dRonin udev rules to allow unprivileged users to access the new Sparky2 USB ID. First post will have a bu_sparky2.opfw attached. Flash this (and run it a few seconds) with your new version LP next or release GCS just before you start using the new version LP code.
The latest Sparky2 code has been changed to have a bootloader that is compatible with the TauLabs bootloader that comes on new Sparky2 boards. This Sparky2 code already merged into next. This means that you do not need to do SBL procedure to get a new Sparky2 board working with LP code. Once this new code is released, you will just flash the LP bootloader updater (bu_sparky2.opfw) using the rescue function of the LP GCS. It is important to run the BU for a few seconds after flashing (just press Boot). After that, use the rescue function of the LP GCS to flash the normal firmware (fw_sparky2.opfw).
For those who already flashed the old, incompatible BL onto their Sparky2 boards, there is a way to avoid doing the SBL procedure again. Don't do this until you have access to the new GCS and firmware.
Do this to avoid doing SBL again on your Sparky2:
- You can uninstall old LP GCS, but it is a good idea to export your settings before you upgrade anything.
- Build or download the new LP sparky2 GCS and firmware (in next right now, soon to be released).
- (Linux) Add new udev rules for the new Sparky2 USB ID (old Sparky2 USB ID was same as Revo).
- Disconnect flight battery power and only use USB for this procedure.
- Leave USB unplugged until instructed to plug it in.
- Use the bu_sparky2.opfw that is attached to this post. It has the new, TL compatible USB IDs.
- Use your new LP GCS. Go to the Firmware tab and press Rescue, then immediately plug Sparky2 into USB.
- After a few seconds, the Open button will appear. Press Open, navigate to and select the bu_sparky2.opfw that you downloaded.
- Ignore the warning about board b01 doesn't match firmware 9201
- Press Flash and wait for the erase and flash to complete.
- When flashing is complete, press Boot to boot the BU. Let it run for 10 seconds.
- Unplug USB from Sparky2.
- Press Rescue again, then immediately plug Sparky2 into USB.
- It should select the correct firmware, or press the Open button, navigate to and select the correct firmware fw_sparky2.opfw
- Press Flash and wait for the erase and flash to complete.
- DONE
- If you can't find fw_sparky2.opfw because you are running the final release, you can do the following:
- Once bu_sparky2.opfw has been flashed and run, you could disconnect USB and then press the Upgrade or Erase-and-Upgrade button (follow the instructions on screen) to install the firmware that comes with the install.
-
@Brunosanta
Sorry for the delay. I haven't been active in the forum lately.
Oplinks settings are a little confusing. To start with, you should export your settings from all your devices in case you want to go back or look at the old settings.
I always make sure there is no other Oplink or Revo that is powered on and could be transmitting. Leave antennas on the devices. Flash the latest (or at least matching) firmware into all your devices (Oplinks, Revos, Sparky2s). Plug your GCS Oplink into USB (no other Oplink, etc running) and configure it like you want it (in particular, check mark the Coordinator box and make sure Coordinator ID is zero). Max power must be higher than zero and baud rate must be at least 57600. Reboot it and make sure the settings are still there. Make a screen capture. Now do the same for the air side (Oplink, Revo, or Sparky2). Plug it into USB without any other Oplinks running. Make the settings match the GCS Oplink except that the Coordinator box should be unchecked and you should copy the "Device ID" from the GCS Oplink screen capture into the "air side" "Coordinator ID" box. Save and reboot the air side board. Make a screen capture of it too. Now you should be able to get them to talk without further configuration. GCS will automatically see the Oplink that is plugged in and when you put a flight battery in the aircraft, the GCS will start receiving telemetry.
If this doesn't fix it, please start a new thread about it.
-
To allow access to the new Sparky2 USB ID under Linux you need to add some udev rules. See update in first post for instructions.
-
hi everyone, hope my experience will help to smbdy -
I got Revolution board and it was not recognized by PC, blue led blinks each 5 sec, and I hear a sound of new device when it blinks, but nothing happened.
I tried STM32 VCP drivers, flashed different versions of bootloader (5 and 6), flashed in DFU mode with pads soldered - no result. the board flashes, firmware updates, but still not recognized by PC and no COM port assigned.
The chinees seller adviced to flash with previous versions of GCS, suggested to start with OP 13.6, than 14.1 and then 15.5.
I was lucky to find only OP 14.1 version and that helped - flashed, the PC asigned a COM port and than I upgraded to 15.5 LP, all works!.
I suggest to organize a repository with old versions of OP, LP for such cases.
-
I suggest to organize a repository with old versions of OP, LP for such cases.
Or simply use the resurrect firmware in first post, a corrupt flash memory should result in a continuous boot/reboot.
-
Hello,
I am trying to get back to LP from Betaflight on my revolution.
But I am not able to load new new bootloader.
Shorting the SBL pin is no problem, green LED lights.
1) GCS does not recognize the controller.
2) I tried your workflow from "Reply #4 on: December 02, 2015"
Using Ardunio as USB-RS232 converter like in your post.
I get following error in cmd
D:\Drohne>stm32flash.exe -w bl_coptercontrol.hex -g 0x0 COM5
stm32flash - http://stm32flash.googlecode.com/
Using Parser : Intel HEX
Serial Config: 57600 8E1
read_byte: No error
Assertion failed: 0, file stm32.c, line 92
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I also tried the .bin file.
3) Tried a workflow with STM loader
http://www.southquay3d.com/index.php?route=news/article&news_id=9 (http://www.southquay3d.com/index.php?route=news/article&news_id=9)
But the STM loader cannot connect the Bootloader
Just an Error
"No response from target, the Boot loader can not be startet.
Please verify the boot configuration and the flash protection status.
Reset DEvice and try again..."
I am really desperate :(
Any ideas?
-
With a Revo board you can use dfu directly like described here:
https://librepilot.atlassian.net/wiki/display/LPDOC/Recover+board+using+DFU
2) I tried your workflow from "Reply #4 on: December 02, 2015"
Using Ardunio as USB-RS232 converter like in your post.
I get following error in cmd
This post is only related to coptercontrol target
-
With a Revo board you can use dfu directly like described here:
https://librepilot.atlassian.net/wiki/display/LPDOC/Recover+board+using+DFU
2) I tried your workflow from "Reply #4 on: December 02, 2015"
Using Ardunio as USB-RS232 converter like in your post.
I get following error in cmd
This post is only related to coptercontrol target
THANK you very much, works great.
Now running LP 16.09 RC2 :D
-
The resurrect fw works. I have recovery as well. Just load the resurrect then load the most current from archive I think it's fw_revo.opfw. Works like a champ
Sent from my iPhone using Tapatalk
-
A version of resurrect has been built into all of the 16.09 versions.
Has anyone found that 16.09RC# did not fix the issue, but using one of these firmwares DID fix the issue?
-
OK - I'm stubborn!
My CC3D (http://www.banggood.com/OpenPilot-CC3D-Flight-Controller-STM32-32-bit-Flexiport-p-937044.html?rmmds=search) was working nicely with LibrePilot. I would be very surprised if this a HW issue. I inspected the board for stray solder etc. and everything looks clean.
I read that I could run BetaFlight on it to gain more capability and was seduced. I used STM Flash Loader Demonstrator and a FTDI to flash "betaflight_3.1.0_CC3D_OPBL.bin" and it bricked it! I only have the Green LED on solid (just as it would be if in SBL) and never the Blue LED that once merrily flashed bootloader-bootloader!!
***All recovery attempts were attempted after solder bridging the SBL pins...***
1) Windows 7 Device manager sees it a USB device, but I cannot manually update the driver. Device Manager error: "Windows has stopped this device because it has reported problems. (Code 43)"
2) FTDI (VCCto5v, Rx to TX, TX to RX Gnd to Gnd) connected to MAIN plug (and alternately - Flex) on CC3D connection attempt: STM Flash Loader Demonstrator reports: "No response from the target the Bootloader cannot be started...
3) Using FTDI and also USB direct to CC3D tried the (Shift+Rclick) CMD (from directory): dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -D whateverfile.bin -s 0x08000000 Since I had nothing to lose, I tried most of the ***.bins
Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to [email protected]
Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
No DFU capable USB device available
4) Using FTDI only, tried the (Shift+Rclick) CMD (from directory): stm32flash -w bl_coptercontrol.hex -g 0x0 COMwhatevernumberyourcomportis Since I had nothing to lose, I tried most of the ***.bins
stm32flash - http://stm32flash.googlecode.com/
Using Parser : Intel HEX
COM26: No error
I know these are a throw away, but it has me BEAT!! I'm hoping that nugget of knowledge to resurrect it can be found here. ;D
What FC should I order to replace it with? I'm not a acro pilot - I just float the quad around the sky....
TIA!!
-
The CC3D do not support DFU, so the dfu-util cannot work.
The two methods are:
- using FTDI: http://www.southquay3d.com/index.php?route=news/article&news_id=9
- using STlink: https://librepilot.atlassian.net/wiki/display/LPDOC/Recover+board+using+ST-Link
-
The CC3D do not support DFU, so the dfu-util cannot work.
The two methods are:
- using FTDI: http://www.southquay3d.com/index.php?route=news/article&news_id=9
- using STlink: https://librepilot.atlassian.net/wiki/display/LPDOC/Recover+board+using+ST-Link
Thanks!!
It seems the STM Flash Loader Demonstrator is a bit finicky! I let windows update the FTDI driver, changes its Comm port to a low number, set its baud to 9600. It took a number of connection attempts, but the STM Flash Loader Demonstrator finally recognized the target and I was able to get the CC3D working once again.