a change to force an error if the passed in ENV var is not defined. If
that had been there, the borkage wouldn't have been undetected.
Changed to only put the main FW in the firmware dir, instead of BL and
FW.
These files do not contain content from the ID in the header.
This name seems to have been cut/pasted all over throughout
the openpilot source tree and should be removed from any files
that should not rightfully be attributed to this person.
It is now easier to trigger warm restarts of a board
via jtag.
Examples:
* make fw_coptercontrol_reset
* make fw_coptercontrol_safeboot
NOTE: These targets are making chip-specific assumptions
so they have to be rewritten to support the F2/F4
boards.
When halted in the bootloader or while rescuing a board, the
user can press the "Safe Boot" button in the uploader gadget
to force the FW to boot with a default hwsettings configuration.
The default conditions of the hwsettings uavo will disable all
optional modules, disable all serial port config, and ensure that
the board can communicate via the USB HID telemetry interface.
Once booted in this mode, a user can easily reconfigure the
hwsettings uavo through the config GUI and save the fixed
settings to the board to be used on the next reboot. No need
to wipe all settings just to recover from a non-functional
HW config.
NOTE: The GCS needs to grow some very clear visual clues to
indicate when the board has booted in safe mode. The
firmware helpfully raises a (new) critical alarm called
BootFault whenever it boots in safe mode.
This can be used by the GCS firmware uploader widget to boot
the firmware with a (temporarily) defaulted hwsettings uavo
so that a user can easily recover from a bad/incompatible
hwsettings configuration without wiping all settings.
This uses the same mechanism that the BootFault auto-recovery
code already uses in the CC firmware. The auto-recovery is
triggered by setting the failed-boot counter to a maximum
value forcing recovery on the next FW init.
The PIOS_COM_ReceiveBufferUsed() function call is no longer
necessary since the same semantics can be achieved using calls
to PIOS_COM_ReceiveBuffer().
Summary of changes:
* USB CDC and HID drivers are completely split apart.
* This will allow different max buffer sizes for HID and CDC.
* USB descriptors have been overhauled:
* Proper structs/macros/enums declared for USB (see pios_usb_defs.h)
* Two common descriptor definitions. One for HID+CDC another for HID only.
See pios_usb_desc_{hid_cdc,hid_only}.c for details.
* Long standing bugs in OP USB descriptors became much more obvious with the
new struct definitions.
* Board specific USB initialization is now in pios_usb_board_data.h in each build target.
* Definition of USB descriptors is now entirely indpendent of STM32 libs.
Glue into STM32 libs is provided by pios_usbhook.c.
* Removed a lot of stale/irrelevant USB #defines throughout the tree.
* Improved naming consistency throughout USB code:
* PIOS_USB_HID_* now refers to the HID endpoint code.
* PIOS_USB_CDC_* now refers to the CDC endpoint code.
* PIOS_USB_* now refers to the low-level USB code.
* PIOS_USB_BOARD_* now refers to board-specific USB data
* PIOS_USBHOOK_* is glue between PIOS and STM32 USB libs.
* struct usb_* and enum usb_* and USB_* and HID_* are all types from the USB spec.
* Shrunk the buffer size on the CDC call mgmt endpoint to save some RAM.
* Made a few more USB related variables static to save some RAM.
This loads the default settings (except output channels) to the GUI page
but does not apply them automatically. User can apply/save them or
reload current values from the board using UAVObjBrowser.
This patch is based on work of Crubier (LPF) and Cossacs (AxisLock mode).
I've just reworked it a bit by adding a dynamic memory allocation for
static module data.
This detects a locked out state and fails the init. The new
bootfault detection code will automatically drop to default
hwsettings after 3 consecutive boot failures. That will put
the board back into an unlocked state where the user can now
enable a telemetry link using the GCS and everything will be
OK.
NOTE: Any configured telemetry link will be considered enough
to boot up. If you only configure a serial telemetry
link but don't know how to hook anything up to it, this
will not save you.
As the ultimate recovery, you can always load firmware on the
board that wipes the settings entirely and start over.
