Quote from: tboy32c on December 30, 2018, 07:38:29 PM

From these quotes I'm not sure if there are actual "bricking" problems or if people are just having trouble with the steps to change firmware. I will confirm that I am able to rollback firmware from the firmware image I posted. If ONLY the red LEDs are showing, then that should mean the control board is in firmware update mode. If the red LEDs are on and you see a blue flashing LED, then the control board is in RUN mode but sgminer has not given it work to do (either sgminer died or the pools are all down, etc). If you see blue solid LEDs then it's hashing. If you don't see any LEDs then your device is not powered Tongue

.

If you run update_fw.py and get:

Code:

dfu-util: No DFU capable USB device available

you can try editing the update_fw.py script by commenting out (adding a "#" at the start of the line) the last couple lines:

Code:

#update_firmware()
#exit_dfumode()

Run the modified script and it should have reset the STM and left it in firmware update mode. Then run:

Code:

lsusb | grep 0483

And the result sholuld be this:

Code:

Bus 007 Device 002: ID 0483:df11 STMicroelectronics STM Device in DFU Mode

(the "device" number will vary)
If instead you get:

Code:

ID 0483:5740 STMicroelectronics STM32F407

we'll have to go from there.

I can not confirm rolling back to 1.2. If i try to, controler board stays in DFU mode (red LEDs). With your custom firmware the device is running fine, but with lower hashrate. (3,5Gh @skein).

I did those steps:

Code:

./opt/scripta/startup/miner-stop.sh
python /usr/bin/update_fw.py
python reset_stm.py
lsusb | grep 0483