[Hackrf-dev] HackRF One update to 2015.07.2 troubles

[Dominic Spill]

On 8 October 2016 at 22:34, Frank Kleinewoerdemann <frankk.work at gmail.com>
wrote:
> On Sat, Oct 8, 2016 at 6:25 PM, Dominic Spill <dominicgs at gmail.com> wrote:
>>
>> > 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.
>>
>> What are the WP and HOLD lines doing while you measure this?
>
> FK: According to the schematic those signals are not on any header or
test point. I'll solder some wires on U20 and advise. Haven't done so yet
as this will probably void any warranty I may have..... IANAL

There's really no need to do this, I was just curious.

>> Instead of using the logic analyzer, could you write firmware to flash
from DFU mode (hackrf_spiflash -w <filename>) and then, without resetting,
attempt to read it back using hackrf_spiflash -r <new_filename> ?  Then
compare those two files to find out if the data is being written to the
flash correctly or not.
>
> FK: I tried to to read the SPI flash with hackrf_spiflash -r <filename>
but the process hangs after printing 'Reading 256 bytes from 0x000000'.
> After sending SIGINT to the process, subsequent hackrf_info returns with
'hackrf_board_id_read() failed: HACKRF_ERROR_LIBUSB (-1000). LED status is
unchanged. Need to reset into DFU mode to recover.

It sounds like there is a problem reading and writing to the SPI flash chip
(U20).  The HackRF firmware likely is getting stuck while trying to read
the flash because it's not getting the response that it expects.

> Reviewing the tools' code it seems that libusb_control_transfer() doesn't
return. Its timeout parameter is set to 0 so it'll wait forever.
> Any idea what could cause this behavior on board level? Would you think
that changing parameters within hackrf.c is worth trying?

I don't think any software changes will fix this, it definitely sounds like
a hardware problem.  While I would imagine that it's a problem with U20
itself rather than the connection to the board, could you take a look and
tell me how the solder joints on U20 look?

Dominic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20161009/98a3d936/attachment.html>