Re: [Hackrf-dev] HackRF One update to 2015.07.2 troubles
On 12 October 2016 at 13:32, Frank Kleinewoerdemann wrote: > > the solder joints on the U20 and the NXP TQFP package look tip-top. Better than on the X3 crystal ;-) > > I got the signals of P81(/WP), P82(/HOLD) and P68(/CS) into the logic analyzer. Set the trigger to /CS falling edge. > > On hackrf_spi flash write, the /HOLD and /WP are high level throughout the write process. The /CS signal is changing only during the first phase of a bock write and remains active low for the remainder of the block write period after the MOSI signal had activity. The rising edge of SCK is neatly aligned with stable MISO and MOSI signals. > > Upon /RESET: the SCK rising edge seems to be mis-aligned to MISO and MOSI signals i.e. the rising edge of SCK is aligned with the rising/falling edge of MISO/MOSI. The /WP and /HOLD line have transitions on them while /CS is active low (apart from some transitions right after /RESET -> high). The /CS, /HOLD and /WP are returned to active high roughly about 2.5ms after /RESET is active high. > It's hard to explain. There's too much going on. Can I upload the logic analyzer capture file for discussion somewhere (its in saleae format)? I'm not certain, but I believe that the LPC4320 reads the firmware from U20 using quad SPI flash rather than regular SPI at boot time. > On hackrf_spiflash -r : Neither SCK nor /CS are driven. At least the logic analyzer can't trigger on either of them. > Perhaps an issue with the firmware to set the SPI port for read operation? I think the issue is a bad SPI flash chip (U20). Could you contact me off list with the details of where you bought the HackRF? Thanks, Dominic > On Sun, Oct 9, 2016 at 11:45 AM, Dominic Spill wrote: >> >> On 8 October 2016 at 22:34, Frank Kleinewoerdemann wrote: >> > On Sat, Oct 8, 2016 at 6:25 PM, Dominic Spill 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 ) and then, without resetting, attempt to read it back using hackrf_spiflash -r ? 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 but the process hangs after printing 'Reading 256 bytes from 0x00'. >> > 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 > > ___ HackRF-dev mailing list HackRF-dev@greatscottgadgets.com https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
Re: [Hackrf-dev] HackRF One update to 2015.07.2 troubles
Hi the solder joints on the U20 and the NXP TQFP package look tip-top. Better than on the X3 crystal ;-) I got the signals of P81(/WP), P82(/HOLD) and P68(/CS) into the logic analyzer. Set the trigger to /CS falling edge. On hackrf_spi flash write, the /HOLD and /WP are high level throughout the write process. The /CS signal is changing only during the first phase of a bock write and remains active low for the remainder of the block write period after the MOSI signal had activity. The rising edge of SCK is neatly aligned with stable MISO and MOSI signals. Upon /RESET: the SCK rising edge seems to be mis-aligned to MISO and MOSI signals i.e. the rising edge of SCK is aligned with the rising/falling edge of MISO/MOSI. The /WP and /HOLD line have transitions on them while /CS is active low (apart from some transitions right after /RESET -> high). The /CS, /HOLD and /WP are returned to active high roughly about 2.5ms after /RESET is active high. It's hard to explain. There's too much going on. Can I upload the logic analyzer capture file for discussion somewhere (its in saleae format)? On hackrf_spiflash -r : Neither SCK nor /CS are driven. At least the logic analyzer can't trigger on either of them. Perhaps an issue with the firmware to set the SPI port for read operation? CU Frank On Sun, Oct 9, 2016 at 11:45 AM, Dominic Spill wrote: > On 8 October 2016 at 22:34, Frank Kleinewoerdemann > wrote: > > On Sat, Oct 8, 2016 at 6:25 PM, Dominic Spill > 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 ) and then, without resetting, > attempt to read it back using hackrf_spiflash -r ? 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 > but the process hangs after printing 'Reading 256 bytes from 0x00'. > > 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 > ___ HackRF-dev mailing list HackRF-dev@greatscottgadgets.com https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
Re: [Hackrf-dev] HackRF One update to 2015.07.2 troubles
On 8 October 2016 at 22:34, Frank Kleinewoerdemann wrote: > On Sat, Oct 8, 2016 at 6:25 PM, Dominic Spill 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 ) and then, without resetting, attempt to read it back using hackrf_spiflash -r ? 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 but the process hangs after printing 'Reading 256 bytes from 0x00'. > 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 ___ HackRF-dev mailing list HackRF-dev@greatscottgadgets.com https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
Re: [Hackrf-dev] HackRF One update to 2015.07.2 troubles
Hi, thanks for your response! Rest is inline. On Sat, Oct 8, 2016 at 6:25 PM, Dominic Spill wrote: > On 5 October 2016 at 10:41, Frank Kleinewoerdemann > wrote: > > > > I had a HackRF One with firmware version 2014.08.1 working with Linux, > Android OTG as well as Windows gear. > > Is 2014.08.1 the firmware that came on the device? > FK: Yes indeed > > 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. > > Whether you perform or skip the CPLD update shouldn't change anything, > there were no CPLD changes between 2014.08 and 2015.07. > > > 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. > > The 0xAB command is to power down the flash, it should be happening at the > end of the write process. > > > 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 > > 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 > > Instead of using the logic analyzer, could you write firmware to flash > from DFU mode (hackrf_spiflash -w ) and then, without resetting, > attempt to read it back using hackrf_spiflash -r ? 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 but the process hangs after printing 'Reading 256 bytes from 0x00'. 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. 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'll connect the logic analyzer again and check all of the U20 signals for write, read, reset and power-on.. > Thanks, > Dominic > ___ HackRF-dev mailing list HackRF-dev@greatscottgadgets.com https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
Re: [Hackrf-dev] HackRF One update to 2015.07.2 troubles
On 5 October 2016 at 10:41, Frank Kleinewoerdemann wrote: > > I had a HackRF One with firmware version 2014.08.1 working with Linux, Android OTG as well as Windows gear. Is 2014.08.1 the firmware that came on the device? > 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. Whether you perform or skip the CPLD update shouldn't change anything, there were no CPLD changes between 2014.08 and 2015.07. > 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. The 0xAB command is to power down the flash, it should be happening at the end of the write process. > 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? > 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 Instead of using the logic analyzer, could you write firmware to flash from DFU mode (hackrf_spiflash -w ) and then, without resetting, attempt to read it back using hackrf_spiflash -r ? Then compare those two files to find out if the data is being written to the flash correctly or not. Thanks, Dominic ___ HackRF-dev mailing list HackRF-dev@greatscottgadgets.com https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
