hackrf/firmware
Martin Ling 79853d2b28 Add a second counter to keep track of bytes transferred by the M4.
With both counters in place, the number of bytes in the buffer is now
indicated by the difference between the M0 and M4 counts.

The M4 count needs to be increased whenever the M4 produces or consumes
data in the USB bulk buffer, so that the two counts remain correctly
synchronised.

There are three places where this is done:

1. When a USB bulk transfer in or out of the buffer completes, the count
   is increased by the number of bytes transferred. This is the most
   common case.

2. At TX startup, the M4 effectively sends the M0 16K of zeroes to
   transmit, before the first host-provided data.

   This is done by zeroing the whole 32K buffer area, and then setting
   up the first bulk transfer to write to the second 16K, whilst the M0
   begins transmission of the first 16K.

   The count is therefore increased by 16K during TX startup, to account
   for the initial 16K of zeros.

3. In sweep mode, some data is discarded. When this is done, the count
   is incremented by the size of the discarded data.

   The USB IRQ is masked whilst doing this, since a read-modify-write is
   required, and the bulk transfer completion callback may be called at
   any point, which also increases the count.
2022-02-13 16:46:12 +00:00
..
2018-03-22 12:29:27 -06:00

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