This error of building any EF targets was found on Windows if used with
make V=1 verbose output option. The '--verbose' python script option was
used by the Windows make as a part of python script file name with
'file not found' error. Now it works. Still can't get the cause of that
error, though...
Moves the CMSIS system_stm3210x.c from library.mk to the individual Makefiles for the F1 targets. This allows for custom SystemInit functions where necessary.
The ST USB code will automatically receive on any
endpoint that is opened but not in the NAK state.
Make sure we set OUT endpoints to NAK initially.
It also happily writes via a NULL pointer in ep->xfer_buff
which writes to address 0x0000_0000. Since address
0x0 is aliased onto the internal flash by the BOOT0/1 pins
and the internal flash is (normally) in the LOCKED state,
this write puts the internal flash into an errored state.
This errored state means that writes to internal flash
are no longer allowed and all further writes fail.
This is required so that we can always respond to HID and
CDC requests via the control endpoint (ep0). The F1/F3
implementation gets away with disabling these interfaces
because all of the ep0 handling is in the usbhook code
rather than (properly) split out into class-specific
drivers like it is done on the F4 implementation.
Conflicts:
flight/targets/DiscoveryF4/System/pios_board.c
flight/targets/FlyingF4/System/pios_board.c
flight/targets/Freedom/System/pios_board.c
flight/targets/Quanton/System/pios_board.c
The CDC descriptor was not advertising support the the line
coding and serial state messages. This was preventing Mac
from sending the SetControlLineState message to indicate
that a DTE (ie terminal program) was present and reading
from the serial port.
We support (and depend on) the DTE indication now so this
was making CDC not work on Mac.
Linux seems to provide the indication regardless of whether
it is advertised in the descriptor or not.
The ST USB code will automatically receive on any
endpoint that is opened but not in the NAK state.
Make sure we set OUT endpoints to NAK initially.
It also happily writes via a NULL pointer in ep->xfer_buff
which writes to address 0x0000_0000. Since address
0x0 is aliased onto the internal flash by the BOOT0/1 pins
and the internal flash is (normally) in the LOCKED state,
this write puts the internal flash into an errored state.
This errored state means that writes to internal flash
are no longer allowed and all further writes fail.
The interface numbers differ for the HID interface between
the BL and FW. This is required to keep windows happy.
In HID+CDC, the CDC interfaces must come first with HID last
which makes it #2. In HID only mode, we can't use #2 for HID
since windows doesn't like the first/only interface to be
anything other than #0.
Conflicts:
flight/targets/board_hw_defs/discoveryf4/board_hw_defs.c
flight/targets/board_hw_defs/flyingf4/board_hw_defs.c
flight/targets/board_hw_defs/freedom/board_hw_defs.c
flight/targets/board_hw_defs/quanton/board_hw_defs.c
USB CDC uses BULK endpoints to send/receive data. Typically,
a USB host will enqueue large buffers on its IN (device-to-host)
URBs. These buffers are larger than the max packet size for the
bulk endpoint.
The USB standard requires that an IN transfer ends when one of
these is true:
* a short packet (ie. less than max packet size) is sent by the
device
* a zero length packet (ZLP)
* enough packets that the entire host buffer is filled
Our device implementation never sends ZLPs. We sometimes send
packets that are exactly max-packet-size bytes long. This would
result in partially filling a host buffer without signalling (via
ZLP) that the transmission had finished. The host would then wait
until the next transfer had taken place before processing the first
data, thus delaying the first data.
This change simply forces all of our transfers to be short packets
and avoids the need to worry about zero length packets. This is
at the cost of some efficiency on the host side since its large
buffers will only ever be partially filled.
Conflicts:
flight/PiOS/STM32F30x/pios_usb_cdc.c
This code was previously passing a pointer to stack
data into PIOS_USBHOOK_CtrlTx() which may be sending
this data asynchronously. Now pass a pointer to
static data so that the asynchronous send doesn't
tx random stack contents.
This code was mistakenly tracking the IN (device-to-host)
requests with data stages. It should have been tracking
the OUT (host-to-device) requests with data stages.
This tracking data is important now that CDC is supported.
CDC actually uses OUT requests with data stages whereas HID
does not. This bug only triggered once CDC was enabled.
CDC and USART device drivers were not all clearing their
device structs before using them.
This specifically caused crashes in the case where the upper
COM layer was binding only a Tx path. The Rx path callback
in the lower driver was uninitialized random data and would
result in the lower driver faulting when it tried to call the
callback.
Conflicts:
flight/PiOS/STM32F30x/pios_usart.c
flight/PiOS/STM32F30x/pios_usb_cdc.c
flight/PiOS/STM32F30x/pios_usb_hid.c
The CDC layer on F1, F3 and F4 now always acts like an
infinte data sink whenever *either* there is no DTE present
(ie. no terminal program listening) *or* the USB cable is
disconnected.
F1 and F4 were previously checking the cable but not the DTE.
F3 didn't check anything. The COM layer didn't even ask the
lower layers.
All of this used to mean that any time a caller did a blocking
send to a CDC device without a DTE, it would eventually block
for up to a 5s timeout waiting for space in the Tx buffer.
Conflicts:
flight/PiOS/STM32F30x/pios_usb_cdc.c
The req parameter is passed to the OUT stage as a convenience.
Since the OUT callback is called *after* the transfer has occurred,
modifying the req would have absolutely no effect. Marking this
as const makes this expectation clear.
Previously, the IN stage on the CTRL interface would write (and
send) its data via the buffer owned by the DATA endpoint. This
would probably have overwritten any data being sent at that
moment. This may have caused data corruption from FC -> GCS.
Now that multiple filesystem partitions are supported,
the UAVO manager needs to be specific about which partition
to load/save its objects to.
Conflicts:
flight/targets/CopterControl/System/pios_board.c
flight/targets/DiscoveryF4/System/pios_board.c
flight/targets/FlyingF3/System/pios_board.c
flight/targets/FlyingF4/System/pios_board.c
flight/targets/Freedom/System/pios_board.c
flight/targets/Quanton/System/pios_board.c
flight/targets/RevoMini/System/pios_board.c
flight/targets/Revolution/System/pios_board.c
flight/uavobjects/uavobjectmanager.c
