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.
ISR, make sure the latency is less than 50 us to avoid framesync errors. Still
seeing a few nonsense packets on Overo side but fairly few. Probably need to
add CRC to whole packet now and call it done.
The board_hw_defs.c file should only contain static
const declarations that only describe the hardware.
All other non-const variables should be put into one
of the pios_board.c files.
ISR. This leads to a possible condition where a copy is taking place in
userspace and then a buffer swap interrupts it. However, the copy should
always finish before the SPI DMA slave catches up to that place in memory at 10
MHz.
This fixes a common condition where the userspace task (low priority) was not
swapping buffers in time from user space and logs were corrupted.
from an ISR. This was causing lock ups. It's a bit higher latency probably
(trivially slow) but if we aren't keeping up with the Overo transactions then
using a proper DMA double buffer will be required.
A separate makefile for EF (Entire Flash) targets allows
the removal of board-specific hard-coded addresses. These
values can now be included from the board-info.mk files
for each board.
These new build targets will construct a flash image that
includes both a bootloader as well as a firmware image all
in one. Examples:
make ef_coptercontrol
make ef_revolution
This also adds support for a new target for writing this EF
image to boards that support a DFU interface (only F4-based
boards). This can be done by running:
make dfuutil_install
# Boot board with SBL asserted to activate STM32 DFU ROM
# Attach USB cable
make ef_revolution_dfu
Bootloader images are also now padded out to occupy the full
BL flash region.
transaction doesn't start at the beginning again. Something is still not quite
right because first few bytes aren't getting across. Need logic analyzer.
transactions should already be completed. Also reset the callback so in the
case of noise on the IRQ line it will not keep firing interrupts.
I suspect we should probably disable interrupts in this handler to prevent
refiring.
The PIOS_MASTER_CLOCK has been removed in favor of
PIOS_SYSCLK (the master clock value,168000000 for revolution)
PIOS_PERIPHERAL_APB1_CLOCK and
PIOS_PERIPHERAL_APB2_CLOCK
Look at STM32F4xx_Revolution.h for the list of timer/peripheral and APB them belongs.
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.
The exti layer now allows drivers to register interrupt callbacks
during board initialization. All details of the driver using a
particular EXTI pin have been removed from the EXTI layer so it
can now be used on any board without board-specific modification.
This includes some nice refinements provided by Mike Smith during
initial review. His original commits have been squashed into this
one.
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.
If no telemetry link is configured, this will force the board
to reset before finishing init. The BootFault logic will
catch this after 3 resets and will boot with default hwsettings
on the next reset.
This won't currently ever fire on OP though since we always
configure the serial telemetry interface. This just makes sure
the pattern is present in case anyone decides to compile without
serial telemetry.
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.
This allows each device to be moved (at compile time) to a
different adapter. This is the first step to allowing devices
to be attached to different i2c adapters.
The main purpose of this new COM implementation is that it is
much simpler, and requires less code space. This takes a bit
of the pressure off of the CC bootloader which was right at
the limit of available code space in the bootloader partition.
This is not intended to ever be used by the application.
This driver also formalizes the assumptions in the bootloader's
usage of the COM layer. All messages are assumed to arrive
in atomic chunks from the HID layer.
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.
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 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.
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.
The GCS hwsettings config widget now disallows any
configuration that disables both HID and VCP telemetry
over the USB port.
The firmware will allow it if the UAVObj is set manually.
This allows a mechanism to reduce RAM usage by another
500 more bytes if USB telemetry can be sacrificed in
certain configurations.
Not all transmitters will continue to run when disconnected.
USB is one example of this. When the USB cable was disconnected,
any transmitter blocked here would wait forever.
This was particularly noticeable when the telemetry Tx task
blocked forever on USB disconnect. This also resulted in
the telemetry Rx task blocking forever waiting on the UAVTalk
connection lock.
We now block for a max of 5s waiting for space in the transmit
buffer.
This allows the HID and VCP functions to be configured
separately so that additional functions can be more easily
bound to the VCP port.
This change also provides a safety net that forces either
the HID or VCP to be configured for USB Telemetry. This
safety net may vanish in the future once the GCS can check
it. Disabling USB Telemetry entirely would save more than
400 bytes of RAM.
The uavtalk layer was previously implementing a poor
version of packet fragmentation based on a hard-coded
max packet size. Since this was hard-coded, there was
no guarantee that it would match the underlying devices.
Now that the COM layer sending routines support fragmentation,
remove fragmentation and use the COM layer directly.
This will support future buffer size reductions in the COM
layer.
PIOS_COM_SendBufferNonBlocking() will now fragment its buffer
to match the max size of the underlying device.
This allows the buffer size of the underlying device to shrink
below the maximum message size, thus allowing us to use smaller
buffers on memory-constrained platforms.
