9f79a16b26
The previous implementation of sweep mode had the M0 continuing to receive and buffer samples during retuning. To avoid using data affected by retuning, the code discarded two 16K blocks of samples after retuning, before transferring one 16K block to the host. However, retuning has to be done with the USB IRQ masked. The M4 byte count cannot be advanced by the bulk transfer completion callback whilst retuning is ongoing. This makes an RX buffer overrun likely, and overruns now stall the M0, causing sweep timing to become inconsistent. It makes much more sense to stop the M0 receiving data during retuning. Using scheduled M0 mode changes between the RX and WAIT modes, it's now possible to do this whilst retaining consistent sweep timing. The comment block added to the start of the `sleep_mode()` function explains the new implementation. The new scheme substantially reduces the timing constraints on the host retrieving the data. Previously, the host had to retrieve each sample block before the M0 overwrote it, which would occur midway through retuning for the next sweep, with samples that were going to be discarded anyway. With the new scheme, buffer space is used efficiently. No data is written to the buffer which will be discarded. The host does not need to finish retrieving each 16K block until its buffer space is due to be reused, which is not until two sweep steps later. A great deal more jitter in the bulk transfer timing can therefore now be tolerated, without affecting sweep timing. If the host does delay the retrieval of a block enough that its buffer space is about to be reused, the M0 now stalls. This in turn will stall the M4 sweep loop, causing the sweep to be paused until there is enough buffer space to continue. Previously, sweeping continued regardless, and the host received corrupted data if it did not keep up.
The primary firmware source code for USB HackRF devices is hackrf_usb. Most of the other directories contain firmware source code for test and development. The common directory contains source code shared by multiple HackRF firmware projects. The cpld directory contains HDL source for the CPLD. The firmware is set up for compilation with the GCC toolchain available here: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads Required dependency: https://github.com/mossmann/libopencm3 If you are using git, the preferred way to install libopencm3 is to use the submodule: $ cd .. $ git submodule init $ git submodule update To build and install a standard firmware image for HackRF One: $ cd hackrf_usb $ mkdir build $ cd build $ cmake .. $ make $ hackrf_spiflash -w hackrf_usb.bin If you have a Jawbreaker, add -DBOARD=JAWBREAKER to the cmake command. If you have a rad1o, use -DBOARD=RAD1O instead. It is possible to use a USB Device Firmware Upgrade (DFU) method to load firmware into RAM. This is normally only required to recover a device that has had faulty firmware loaded, but it can also be useful for firmware developers. For loading firmware into RAM with DFU you will need: http://dfu-util.sourceforge.net/ To start up HackRF One in DFU mode, hold down the DFU button while powering it on or while pressing and releasing the RESET button. Release the DFU button after the 3V3 LED illuminates. A .dfu file is built by default when building firmware. Alternatively you can use a known good .dfu file from a release package. Load the firmware into RAM with: $ dfu-util --device 1fc9:000c --alt 0 --download hackrf_usb.dfu