[Hackrf-dev] HackRF One update to 2015.07.2 troubles

[Frank Kleinewoerdemann]

Hi,

I had a HackRF One with firmware version 2014.08.1 working with Linux,
Android OTG as well as Windows gear.

I decided to give the 2015.07.2 firmware a go and followed the procedure as
per https://github.com/mossmann/hackrf/wiki/Updating-Firmware up to step 1
(reset after rom-to-ram binary SPI flash). Result: The 3V3 LED is lit and
the RF as well as the TX LED are dimly lit. No 1V8, RF or USB are lit. The
hackrf unit is no longer booting....

I know that there were several reports in the past about this problem but
the discussions did not provide fix / working solution (apart from one
miraculous recovery perhaps....).

I got the error that the board isn't found anymore with $ hackrf_info.

I thus rebuild the host tools as per hackrf-2015.07.2/host/README.md,
disconnected and reconnected the device. No hint in dmesg that there is a
USB device.

I entered the DFU mode and got

$ dmesg

[10510.780314] usb 1-1: new high-speed USB device number 29 using ehci-pci
[10510.914474] usb 1-1: New USB device found, idVendor=1fc9, idProduct=000c
[10510.914491] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[10510.914501] usb 1-1: Product: LPC
[10510.914510] usb 1-1: Manufacturer: NXP
[10510.914519] usb 1-1: SerialNumber: ABCD

then after

$ dfu-util --device 1fc9:000c --alt 0 --download hackrf_one_usb_ram.dfu
The dfu-util advised: unable to read DFU status after completion

$ dmesg

[10525.332472] usb 1-1: USB disconnect, device number 29
[10525.604269] usb 1-1: new high-speed USB device number 30 using ehci-pci
[10525.743350] usb 1-1: New USB device found, idVendor=1d50, idProduct=6089
[10525.743366] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=5
[10525.743377] usb 1-1: Product: HackRF One
[10525.743386] usb 1-1: Manufacturer: Great Scott Gadgets
[10525.743396] usb 1-1: SerialNumber: 0000000000000000453c64c8216f798f
[10525.745631] hackrf 1-1:1.0: Board ID: 02
[10525.745649] hackrf 1-1:1.0: Firmware version: 2015.07.2
[10525.746010] hackrf 1-1:1.0: Registered as swradio0
[10525.746270] hackrf 1-1:1.0: Registered as swradio1
[10525.746286] hackrf 1-1:1.0: SDR API is still slightly experimental and
functionality changes may follow

No I got the device in working order.

$ hackrf_info
Found HackRF board 0:
USB descriptor string: 0000000000000000453c64c8216f798f
Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2
Part ID Number: 0xa000cb3c 0x00394f4e
Serial Number: 0x00000000 0x00000000 0x453c64c8 0x216f798f

$ lsusb
...
Bus 001 Device 034: ID 1d50:6089 OpenMoko, Inc.
...

Then I proceded with "Updating-Firmware" step 2:

$ hackrf_spiflash -w hackrf_one_usb_rom_to_ram.bin
File size 20452 bytes.
Erasing SPI flash.
Writing 20452 bytes at 0x000000.

skipped the reset and issued
$ hackrf_cpldjtag -x hackrf_cpld_default.xsvf

Got the USB, RX and TX LEDs blinking.
Disconnected the USB cable.
Reconnected the USB cable.
Same LED status as before the DFU mode. Board isn't recognized. Nothing
turns up with lsusb.
If I skip the CPLD update and press the reset button: LED 3V3 on, RF on,
all others off. Power cycle gets me back to where I was after the first SPI
flash.

I put a logic analyzer on the exposed SPI pins (on the P20 header) and
could observe that the binary data was present on the SPI during flash
operation - plus blocks of [0xAB, 0xFF (times 4)] repeated 21 times plus
what seems to be an incremental count value.
There is also SPI data after reset/reboot but it's not what was sent to the
SPI flash and the clock signal in relation to MOSI/MISO looks rather odd
(like misaligned...clock rising edge vs.stable level on MISO/MOSI). I can't
tell though whether this is expected or not.

Please let me know if you have an idea what to do in order to get the
device booting again without passing through the DFU mode.
Some hints as how the SPI data should look like after reset could be
helpful as well....

Best regards,

Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20161005/70405e4f/attachment.html>