Use EP0 OUT flow control to NAK OUT packets when we're not yet expecting
any. This prevents the status OUT event from arriving while the control
state machine is still expecting the data IN completion event.
Use REBASE(OTG_FIFO(endpoint)) to access the FIFO.
For the receive FIFO do not use the endpoint. There
is only one receive FIFO so giving the endpoint is
a no-op.
Get rid of REBASE_FIFO macro.
When reading a portion of the packet that is not divisible by 4 and
not equal to rxbcnt the count could get off, since 4 bytes are read
from the fifo in the last step but rxbcnt was only updated by the
number of bytes the caller requested.
We fix this by always subtracting four bytes (the number of bytes
read from the fifo) when we read a word from the fifo. Care has
to be taken in the last step so that rxbcnt doesn't underflow (it
is an unsigned number).
Note that reading in several small chunks not divisible by 4 doesn't
work as the extra bytes read in the last step are always discarded.
After a SETUP packet on a control endpoint the transmit FIFO
should usually be empty. If something bad happened, e.g. PC
and device got out of sync, we want to clear the fifo.
This should fix#668.
This is to interrupt for setup sequences on IN packet before
checking for OUT packet received. This fixes the problem that
usb_control_out stalls because we are not yet in STATUS_OUT phase.
Related to #668.
Went awol merging something :(
(Yes, dwc_otg is theoretically shared with efm and co, but at present
it's still pretty much the stm32 version)
Fixes: 422d708384c76b8bf3a860bdd084e3010e28afa0
Control transfers can transfer less than was requested by the host in the
wLength field. if this short transfer is a multiple of the endpoint's packet
size, a zero length packet must be sent.
Adds tests for a range of control transfer IN requests, and properly supports
this in the core. Based heavily on work by Kuldeep Dhaka.
See https://github.com/libopencm3/libopencm3/pull/505
and https://github.com/libopencm3/libopencm3/pull/194 for original discussion.
Tested with stm32f4, stm32f103 and stm32l053.
The breaking changes here changes in header location, and changes in driver
name passed down to the usb stack.
Changes affect: stm32f102/f103, stm32l1, and some f3 parts
* instead of the confusingly generic "usb" use the name "st_usbfs" for the USB
Full speed peripheral ST provides in a variety of their stm32 products.
Include directives should change as:
#include <libopencm3/stm32/usb.h> => <libopencm3/stm32/st_usbfs.h>
* instead of the confusingly specific "f103" name for the driver, use
"st_usbfs_v1" [BREAKING_CHANGE]
Instead of:
usbd_init(&stm32f103_usb_driver, .....) ==>
usbd_init(&st_usbfs_v1_usb_driver, .....) ==>
The purpose of these changes is to reduce some confusion around naming, but
primarily to prepare for the "v2" peripheral available on stm32f0/l0 and some
f3 devices.
Work by Frantisek Burian, Kuldeep Singh Dhaka, Robin Kreis, fenugrec and zyp
on irc, and all those forgotten.
Setting the same configuration again should act as a lightweight reset, not be
ignored. This resulted in data toggle bits not being reset and alternet
settings not being reset.
Further, completely invalid configurations were accepted, when they should have
result in a stall. (Section 9.4.7 of USB 2.0 spec)
fixes Github issue #302
Tested-by: Karl Palsson <karlp@tweak.net.au>
* USB host register definitions added.
* Extracted common register and bitfield definitions
from 'otg_fs.h' and 'otg_hs.h'
into new file 'otg_common.h'.
Modified usb low-level drivers to adopt to new style of bitfields.
* Fixed typo OTG_GOTGIN -> OTG_GOTGINT (according to the datasheet)
Signed-off-by: Amir Hammad <amir.hammad@hotmail.com>
This makes it easier to read for most people, and makes it substantially
easier to review changes in the function signatures themselves at a
later date.
Regression from 0cc0134f21b387a3a813feca1973c77587900ee2
When operating on registers in code that is common for both usb cores,
make sure to use the REBASE macros to operate on the correct peripheral.
Reported by: kuldeep
Fixes github issue: #495
The three existing usb drivers have no possible path that doesn't return
the object here, so I've left that comment, but it is plausible that
future drivers might have some reason that allows failing to init. We
should strive to avoid that though.
Fixes github issue: #494
This commit implements the support for one interface to have multiple
altsettings. It also adds hook that user can use to perform actions
when the alsetting switch is performed by host.
Changes:
* For backward compatibility, placed a pointer instead of allocating memory for whole interface struct.
* Always execute callback (even if the current interface alternate-settings matches).
* Multiple configuration support.
Signed-off-by: Kuldeep Singh Dhaka <kuldeepdhaka9@gmail.com>
USB using control callbacks was broken since d6bad27735a77b8daa90ce72b843cf08ba78697d
Properly check if user usb control callback are registered,
while here make sure user_callback_set_config callback pointers are initialized to NULL.
Extends struct usb_endpoint_descriptor to make it possible to provide
the USB host with class-specific extensions to endpoint descriptors.
The approach taken, based on extra and extralen and removing the sizeof()
from USB_DT_ENDPOINT_SIZE, is identical to the approach used to add
class-specific extensions to interface descriptors. All libopencm3-examples
use the USB_DT_ENDPOINT_SIZE (rather than directly using sizeof) so there
should be no compatibility problems resulting from this change.
If there is no additional iface data then iface->extra is NULL and
iface->extralen is zero. Passing NULL to memcpy is undefined behaviour
even if the length of data to copy is zero. In other words a conforming
(debug) memcpy implementation is permitted to assert(dst && src) without
checking the value of n.
Add an extra branch to avoid this.
In a composite device if one want to separate code
for each interface, usbd_register_set_config_callback
can now register more than one callback.
Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
The f103 usb core should be usable on the l1 as well, and the /f1/rcc
isn't explicitly required anymore. This is an important change to be
able to share the driver.
After a STALL handshake is transmitted, a control pipe becomes idle. Not
marking the pipe as idle did not affect the STM32 family. Since it
distinguishes between OUT and SETUP tokens, it calls the setup handler
on a SETUP token, regardless of the state of the pipe.
Other families, such as LM4F do not distinguish in software between IN and
SETUP tokens, and need to decide which handler to call based on the state
of the pipe. On these chips, SETUP transactions will not be handled
properly after a transfer was STALLED, as the state machine of the pipe is
b0rked. Unb0rk it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We should not add compiler extensions, it is not our job. We are not a
selfcontained project as kernel is so we should not introduce things
like this.
If we need to add some abstraction for this in the future to support
compilers doing these things differently then we will do that the same
way we dealt with the depricated attribute.
In places where we were defining memory mapped peripheral buffers we
were using directly a cast to "volatile int_type *". For consistency we
should use dereferenced accessor like: &MMIO32(address)
Added --terse and --mailback options to the make stylecheck target. It
also does continue even if it enounters a possible error.
We decided on two exceptions from the linux kernel coding standard:
- Empty wait while loops may end with ; on the same line.
- All blocks after while, if, for have to be in brackets even if they
only contain one statement. Otherwise it is easy to introduce an
error.
Checkpatch needs to be adapted to reflect those changes.
Current way of having a globally, but weakly defined static buffer has
several shortcomings:
- It forces user to have a certain "magic" byte array variable if
they want to have a control buffer of different size.
- Having a globally defined static array and a separate function to
tell USB core about its size is error prone.
- Its inner workings are not easily understandable form cursory look
at API and one needs to go and look at the implementation code to
connect all the pieces into a solid picture of how it works
This commit adds two parameters to 'usbd_init' call that allow user to
specify the pointer to the area of memory and a size of that memory
which would be used by the USB core to store the data received during
DATA stage of control requests. This approach, while further
complicating the prototype of 'usbd_init', provides user with more
flexibility allowing for any custom area of memory of any size to be
used as control buffer. It also forces user to provide both address
and memory size at the same time thus avoiding the possibility of user
redefining 'usbd_control_buffer', but not calling
'usbd_set_control_buffer_size' after that.
This commit refactors USB string code, making it, hopefully, less
buggy and more easier to understand. It also removes "magic" bit
manipulation and "magic" numbers;
This commits adds a new error code that can be return from a
registered control callback: USBD_REQ_NEXT_CALLBACK. This return code
signifies that the callback is done processing the data successfully,
but user would like to have all matching callbacks down the callback
chain to be executed too.
This change allows for example to intercept standard requests like
GET_DESCRIPTOR, do some small action upon receiving of one, but still
have the standard callback executed and do it's job. This way user
doesn't have to re-implement standard GET_DESCRIPTOR functionality if
they want to intercept that request to do some small thing.
