Won't boot
If you device won't boot and leaves you on white screen, then you will need to power off the device and then hold down the UP button while you power it on. This could take up to 10 seconds.
If this does not work, then try the same thing but this time holding the DOWN button (Remembering to wait up to 10 seconds).
What this is doing is loading a different LCD driver to get your devices screen to work.
Once that is done you should be able to reboot normally without any issues.
If you device won't boot and leaves you on a black screen, then you will need to power off the device and then hold down the LEFT button while you power it on. This could take up to 10 seconds.
- UP key = LCD driver 1
- DOWN key = LCD driver 2
- OK/SELECT key = Reset/Automatic detection
- LEFT key = LCD driver 2 QFP100 chip
- RIGHT key = LCD driver 1 QFP100 chip
Note: H2+ usually require you to hold the UP key on the first boot to configure them.
This is valid from nightly version n_220412 and stable release version: v1.5.1
H2+ (and H1) not powering up , just black LCD (after flashing new Mayhem fw, and it is ignoring previous above key buttons init description ):
If your device was working correctly before updating the fw , and now you just got black screen after been reflashed and it is ignoring the keyboard of the above instructions and looks like bricked , you have several options , depending the case that you have :
(showing in the front of the HackRF board a green LED when plug in USB cable ) , You are lucky , it means that your device is in “hackrf mode” , with good USB communication ,
(2) if you have an H1 device (without integrated battery) that does not detect any USB communication,
(usually no need to be disassembled ), Just try to set up it to DFU mode , And after, Send from terminal that following command
Type dfu-util --device 1fc9:000c --alt 0 --download hackrf_one_usb.dfu
You will see from that point that the USB LED from the Hackrf becomes active. You can confirm it , with linux command lsub ==> we are in hackrf mode, with green LED when connecting USB cable to the USB),
(in my case , there is no way to put it into DFU mode without disassembling and separating Hackrf from Portapack ) ,
In that case, Dissassembly carefully both boards from the metal case box .
Separate with maximum care to not bend / force so much the PCB's and the LCD Panel , both boards (Hackrf - Portapack) , It is a matter of patience , step by step from both connectors , trying to keep coplanarity of both boards ,
(A) pick up your hackrf board ,
connect it to USB, If it's not bricked , you will have a green LED when plugging USB. if it is bricked you will need to set up to DFU mode
And after, Send from terminal that following command (to put your device in correct “Hackrf mode” (with green LED when connecting USB cable to the USB),
Type dfu-util --device 1fc9:000c --alt 0 --download hackrf_one_usb.dfu
You will see from that point that the USB LED from the Hackrf becomes active. You can confirm it , with linux command lsub ==> we are in hackrf mode,
Assuming that you are here, with already in correct Hackrf mode (with green LED when connecting USB cable to the USB),
In case that you have H2+ Portapack with big CPLD QFP100, flash it with special fw jumbo77 1.43 first
In case that you have H1/H2+ Portapack with standard small CPLD QFP64, flash it with official Mayhem fw 1.43 first
If you came from (3) case , assemble both boards again.
Then , (a) Confirm correct boot power up of fw version 1.43 (special jumbo 1.4.3 for big CPLD QFP100, or official 1.4.3 for std CPLD QFP64)
(b) From that 1.43 fw ,with correct boot, put the device in “hackRF mode” and flash it again, but now with latest Mayhem firmware.
(c) At first power up, keep pressing the appropriate button for your unit for more than 2 secs, until getting correct LCD display, and it should work all correctly !
Firmware starting at version 1.5.4 and onward contain the Pull Request 662 that uses the persistent memory to test and store the hardware and LCD config settings . That memory uses the same back up voltage than the Real Time Clock calendar, both needs a healthy cell battery button voltage. Sometimes, in a re flashing process , although we got good battery cell button voltage, the unit seems to be badly initializing those persistent bytes and we got strange black screen. Doing those above steps probably reset the persistent memory. That's just a guess.