[utoedter]

Hello folks,

Today i noticed a problem with my chinese Revolution Mini. The firmware Tab shows Bootloader 6 and 16.09 Firmware version what is correct so far. I tried to flash the latest version from git.   The board starts to shuts dows but doesnt complete the procedure,  but the LED is fading. After a while its times out, and from that point nothing is possible. In the top right corner the BL Version is shown with a "?". Rescue is also impossible, same result. Is there a way to recover the board with dfu or st-link? Cant find those SBL points on board, and the socket, which is required for using ST-Link is not on the board. The board itself runs fine, exept the firmware upgrade.

Help is very welcome.

Udo

[f5soh]

DFU procedure is described here

SBL pads for RevoMini:

[utoedter]

Thank you, thats very helpfull ... and those are  very very tiny .....

Update:

Decided not to solder them, but masked the board except the pad with isolating tape and shorten the pads with a little piece of aluminium foil, that booted the board into the STM-32 mode. Choose the entire flash inside the rescue pack to write bootloader and firmware. That worked fine, after a minute i had 15.09 on the board. Tried to update the firmware via the Firmware Tab showed the same problems as before, board is still unable to enter DFU mode, even with complete rewritten bootloader and firmware, but this time with 15.09 on the board. *rolleyes*. So i extracted the 16.09 entire flash for Revolution from the firmware .tar file,  copied that file into the LibrePilot DFU flash directory, set the board again into STM-32 mode and updated to the current release.

What i have learned:

1. My board is proably a little bit damaged, yes lord i was a sinner, because i tried Dronin on the board.
2. Its not totally bricked, because the manual update via dfu-util and shorten SBL pads still work.

My wish:

To safe others from the same problem, please include the latest firmware releases into the Librepilot DFU flash package.
Udo

[f5soh]

After you flashed the entire flash or just the bootloader (using bl_revolution.bin or ef_revolution.bin files) you will be able to flash the matching firmware using the manual update.
- Disconnect board
- Upgrade&Erase button
- Connect board

The only part you need is the correct bootloader flashed into the board.

[TheOtherCliff]

There is a thing about running TauLabs or others on it and then trying LP.  The other firmware changes the flash storage and that makes LP think there is corrupt flight logs on it.  That should be handled automatically by 16.09.  It should detect it and format the flash.  It might take it even a whole minute to do it?

Look for unbrick on the forum and flash one of the special firmwares if you want to try it...

[utoedter]

Yes, ive found that firmware, its a .opfw file. Can that be used with the dfu-util, because all other files in the DFU pack are just .bin files. And, i ran the dfu executable via USB, will a FTDI adapter connected to the main port work better?

Udo

[f5soh]

.opfw are flashed just using GCS and rescue method

DFU method is usually done using USB port for F4 and F3 cpu.
FTDI and Mainport is needed for F1 like CC3D.
Another method is using ST-Link and SWD port/connector.

[utoedter]

.opfw are flashed just using GCS and rescue method

DFU method is usually done using USB port for F4 and F3 cpu.
FTDI and Mainport is needed for F1 like CC3D.
Another method is using ST-Link and SWD port/connector.

So far i wasnt successfull with all those hints :-(

What works:
 - Taulabs can be flashed via dfu util as entire flash .... thats works

Via DFU Util i can flash:

- Any version of Revolution LP ef_ and bl_ .bin files, that brings me to a booting LP board, but any writes to the board
  bring me into the boot loop.
- Rescue Firmware as opfw File cant be flashed, because the rescue method times out, if fails to detect the bootloader, because
   the boards boots normal
- Upgrade/Erase bringing the board into a slow pulsing blue led and time then out .
- Any Halt/Reboot from the Firmware Tab ends at sending IAP3 then timeout

.opfw cant be flashed via dfu-util, so my question are:

1. Can i erase the complete board except the SBL loader with a .bin file which i can create easy with dd if=/dev/zero  on my linux box? And write then everything from scratch?

2. Can the .opfw resurrect file converted into a ef_resurrect.bin file, because dfu-util is the only one way to load the board with firmware.

Logfile from flashing the ef_ for revolution:

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!!!
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 786432
Download        [=========================] 100%       786432 bytes
Download done.
File downloaded successfully

Remove the solder join between SBL pads!!
Drücken Sie eine beliebige Taste . . .

Udo 

[TheOtherCliff]

The fact that TL works, really makes it sound like a standard "bricked by TL flight log in user flash area" which is what the unbricking firmwares are supposed to fix.  Also, the latest LP firmware should have automatic unbricking built in at this point, but it is different code...

These old unbricking firmwares still work, but won't show up correctly when plugged into a current LP GCS.

I think I heard that you can flash opfw files from TL GCS.

For sure, flashing an ef*.bin with dfu-util should cure all problems except for "bricked by TL flight log in user flash area"

For sure, flashing a bl*.bin or an ef*.bin with dfu-util puts a working LP bootloader on the board.

Then using LP GCS manual rescue to flash unbricking firmware, then run the unbricking firmware for 60 seconds, then using LP GCS manual rescue to flash normal firmware should fix it if it is that problem.

Not 100% sure if you have tried flashing LP firmware via the manual rescue method:
- must have a working LP bootloader to begin with
- click Rescue
- then plug in USB
- then select which firmware to flash (Open) and Flash it
you should be able to flash any opfw file this way.  In particular I would try some of the Revo unbrick firmwares.  Also you can install a bootloader updater opfw this way.

Bootloader updater (bu file) is a normal firmware that is loaded into the normal firmware location and once it is run, it writes itself into the bootloader location, so:
 - you must reboot and let it run (for say 60 seconds) after flashing so that it can copy itself to the bootloader location
 - it overwrites the normal firmware, and you asked for a way to do that
 - since the BU wipes out the normal firmware, you must use something like the manual rescue method to put normal firmware on the FC after flashing then running the BU

[utoedter]

The fact that TL works, really makes it sound like a standard "bricked by TL flight log in user flash area" which is what the unbricking firmwares are supposed to fix.  Also, the latest LP firmware should have automatic unbricking built in at this point, but it is different code...

These old unbricking firmwares still work, but won't show up correctly when plugged into a current LP GCS.

I think I heard that you can flash opfw files from TL GCS.

For sure, flashing an ef*.bin with dfu-util should cure all problems except for "bricked by TL flight log in user flash area"

For sure, flashing a bl*.bin or an ef*.bin with dfu-util puts a working LP bootloader on the board.

Then using LP GCS manual rescue to flash unbricking firmware, then run the unbricking firmware for 60 seconds, then using LP GCS manual rescue to flash normal firmware should fix it if it is that problem.

Not 100% sure if you have tried flashing LP firmware via the manual rescue method:
- must have a working LP bootloader to begin with
- click Rescue
- then plug in USB
- then select which firmware to flash (Open) and Flash it
you should be able to flash any opfw file this way.  In particular I would try some of the Revo unbrick firmwares.  Also you can install a bootloader updater opfw this way.

Bootloader updater (bu file) is a normal firmware that is loaded into the normal firmware location and once it is run, it writes itself into the bootloader location, so:
 - you must reboot and let it run (for say 60 seconds) after flashing so that it can copy itself to the bootloader location
 - it overwrites the normal firmware, and you asked for a way to do that
 - since the BU wipes out the normal firmware, you must use something like the manual rescue method to put normal firmware on the FC after flashing then running the BU

Problem is solved but in a unusual way. Problem was, the Rescue method didnt work for me, not even manual, i had no flash button at all.  Let me repeat, instead to going into boot loader mode via the rescue method, the board started Taulabs. Changing the BL to the LP BL worked only via the dfu-util, flashing the ef_ file too, but changes to the config ended with boot loop.

What i did:

Downloaded the latest portable dronin release (forgive me again lord), wrote the Dronin BL via dfu-util to the board and changed to dronin. Works fine as an intermedia step. Rescued with flashing Dronin FW to the board, erased all settings.

Switched back to LP, rescue ... Wohoo this time the board was recognized, so i flashed LP back to the board. Board works now, but only with the Dronin boot loader. The LP boot loader still causes problems.

Thank you for all your help
Udo