Removes hard-coding of JTAG interface config in the
<board>_program make macros.
This allows the use of STLINKv2 for F4 boards while
continuing to use the FOSS JTAG revB on F1 boards.
for sensing and then load different config for CC and CC3D. Updated the
bootloader as well. Also changed the PIOS_USB_CheckAvailability function to
only return the sense signal and not the transfer_possible flag as this is not
set in time for the bootloader on CC3D for some reason.
Board specific HW configuration is now collected in a single .c
file for each board. This HW configuration is #include'd into
the FW, BL and BU builds for each board.
These new .c files are found in:
flight/board_hw_defs/<board_name>/board_hw_defs.c
Parts of this information were previously duplicated between
the BL and FW builds. This commit cleans up the duplication.
Using a #include on a .c file is a bit ugly but it allows us
to ensure that all of the symbols in the board_hw_defs.c file
are *ONLY* used in the PIOS_Board_Init() function for each
software build.
OpenPilot platform (and thus sim too) was missed when the
DIAG_TASKS macro was broken out from the DIAGNOSTICS macro.
This allowed accesses to the TaskInfo UAVO even though it hadn't
been initialized.
Some modules are written such that they can be included
or excluded at runtime. These are added to the OPTMODULES
list in the makefile for a given board.
This change provides a mechanism to allow a build to force
a given module to be built-in (ie. always initialized)
regardless of the configuration in hwsettings.
The main use case for this is to handle a module being optional
on one platform but essential on another.
All modules added to the MODULES list in the Makefile will
automatically result in a matching #define in the form
MODULE_TheModuleName_BUILTIN
being defined in the CFLAGS for all compiled source.
Note that the capitalization of TheModuleName must match
exactly the capitalization used in the MODULES list.
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 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.
This module and its associated settings uavo can be used
to test various fault conditions during initialization.
To enable the module, add the TEST_FAULTS=YES to your make
command line:
make fw_coptercontrol TEST_FAULTS=YES
Once this module is part of your firmware load, you can
enable it in the hwsettings uavo and then select the
type of fault to insert by editing the faultsettings uavo.
On the next reset, the configured fault will be inserted
into the init sequence to allow you to test the boot fault
recovery code.
With a fault inserted, you should see 3 failed boot attempts
followed by a successful (recovery) boot. You will see the
BootFault alarm set to Critical, and the RAM version of your
hwsettings will be reset to defaults. Since the defaults have
all optional modules disabled, the fault module will be out of
the way during the recovery boot.
You can then "Load" the flash version of the hwsettings uavo
in the object browser, disable the Fault module and then "Save"
the hwsettings module back to the board. The next reset will
boot normally without the fault inserted.
After 3 failed warm start attempts, the init sequence
will force the RAM version of the HWSettings object
to its defaults. This should allow a user to regain
connectivity to a board that is continually faulting
during init.
This is accomplished by:
- Incrementing a boot counter that is stored in the
STM32 BKP registers. These registers survive a
warm start but are cleared on a cold start (ie. powerup).
- On multiple failures, force hwsettings to defaults
and raise the (new) BootFault alarm to prevent arming.
- Resetting the boot counter whenever the system manages
to successfully run the System Module task.
NOTE: This does not actually change the hwsettings object in
flash. That's up to the user.
This is intended to catch ONLY faults during early initialization.
It should not be used to recover from faults after the application
is up and running.
