f3633e285f
This change avoids various possible races in which an autonomous mode change by the M0 might clobber a mode change made from the M4, as well as related races on other state fields that can be written by the M4. The previous mode field is replaced by two separate ones: - active_mode, which is written only by the M0, and indicates the current operating mode. - requested_mode, which is written by the M4 to request a change. This field includes both the requested mode, and a flag bit. The M4 writes the field with the flag bit set, and must then wait for the M0 to signal completion of the request by clearing the flag bit. Whilst the M4 is blocked waiting for the flag bit to be cleared, the M0 can safely make all the required changes to the state that are needed for the transition to the requested mode. Once the transition is complete, the M0 clears the flag bit and the M4 continues execution. Request handling is implemented in the idle loop. To handle requests, mode-specific loops simply need to check the request flag and branch to idle if it is set. A request from the M4 to change modes will always require passing through the idle loop, and is not subject to timing guarantees. Only transitions made autonomously by the M0 have guaranteed timing constraints. The work previously done in reset_counts is now implemented as part of the request handling, so the tx_start, rx_start and wait_start labels are no longer required. An extra two cycles are required in the TX shortfall path because we must now load the active mode to check whether we are in TX_START. Two cycles are saved in the normal TX path because updating the active mode to TX_RUN can now be done without checking the previous value.
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