hackrf/firmware
Martin Ling 361c4ac54f Move transceiver mode changes out of USB ISR.
This is a defensive change to make the transceiver code easier to reason
about, and to avoid the possibility of races such as that seen in #1042.

Previously, set_transceiver_mode() was called in the vendor request
handler for the SET_TRANSCEIVER_MODE request, as well in the callback
for a USB configuration change. Both these calls are made from the USB0
ISR, so could interrupt the rx_mode(), tx_mode() and sweep_mode()
functions at any point. It was hard to tell if this was safe.

Instead, set_transceiver_mode() has been removed, and its work is split
into three parts:

- request_transceiver_mode(), which is safe to call from ISR context.
  All this function does is update the requested mode and increment a
  sequence number. This builds on work already done in PR #1029, but
  the interface has been simplified to use a shared volatile structure.

- transceiver_startup(), which transitions the transceiver from an idle
  state to the configuration required for a specific mode, including
  setting up the RF path, configuring the M0, adjusting LEDs and UI etc.

- transceiver_shutdown(), which transitions the transceiver back to an
  idle state.

The *_mode() functions that implement the transceiver modes now call
transceiver_startup() before starting work, and transceiver_shutdown()
before returning, and all this happens in the main thread of execution.

As such, it is now guaranteed that all the steps involved happen in a
consistent order, with the transceiver starting from an idle state, and
being returned to an idle state before control returns to the main loop.

For consistency of interface, an off_mode() function has been added to
implement the behaviour of the OFF transceiver mode. Since the
transceiver is already guaranteed to be in an idle state when this is
called, the only work required is to set the UI mode and wait for a new
mode request.
2022-02-08 13:45:41 +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