| Age | Commit message (Collapse) | Author |
|---|
|
|
|
OTG FS has 4 endpoints, but OTG HS has 8.
Restore default value of the count of endpoints
and add the possibility to redefine it
|
|
|
|
|
|
# Conflicts:
# lib/stm32/f2/Makefile
# lib/stm32/f4/Makefile
|
|
|
|
|
|
|
|
Signed-off-by: Ilya Stolyarov <i.stolyarov@thirdpin.ru>
|
|
Signed-off-by: Ilya Stolyarov <i.stolyarov@thirdpin.ru>
|
|
|
|
|
|
See https://github.com/libopencm3/libopencm3/issues/873
Commentary describing this patch originally by zyp:
```
After looking further into it, I've concluded that my preliminary
analysis looks correct. The problem is that setting CNAK before
the SETUP complete event is received causes a race condition. The
SETUP callback is called when the SETUP packet event is received,
which means that setting CNAK from the callback is too early.
Originally the problem was that CNAK was set by ep_read() which is
called by the callback. #672 solved this by moving CNAK out of
ep_read() and calling it after the SETUP complete event is received
instead.
The regression by #785 is caused by the introduction of flow control
calls into the SETUP callback. They also set CNAK.
To solve this properly, I propose changing the event handling code
to only call the SETUP callback after the SETUP complete event is
received. Unfortunately, this implies that the callback can't call
ep_read() itself anymore, because the packet has to be read out of
the FIFO before the SETUP complete event arrives. This implies a
change of the API between the hardware drivers and _usbd_control_setup().
```
L1 (st_usbfs) works and passes tests as before change
F4 (dwc_otg_fs) works and now passes tests. (yay)
LM4f still compiles, and has had the same style of implementation as
st_usbfs, however has not been tested on any hardware.
|
|
usb_disconnect() is board/platform specific for chips that don't have
built-in handling for this. Allow the application to provide its own
version of usb_disconnect() to handle this.
See https://github.com/libopencm3/libopencm3/pull/924
|
|
This allows the pointer table to be in Flash, by using
"static const char * const strings[] = { ... };"
See https://github.com/libopencm3/libopencm3/pull/924
|
|
Originally discussed at https://github.com/libopencm3/libopencm3/pull/722
|
|
Somewhat replaces some earlier work done by hg/lg, but much more
complete, so we kept it as is, because it's bringing in even more parts
after this.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
|
|
The enum usbd_request_return_codes has been available for some time. It
should be used internally, not just by users of this code.
|
|
Fixes https://github.com/libopencm3/libopencm3/issues/409
|
|
|
|
|
|
This is required to support armv6m targets using this code.
|
|
The stm32fx07 is common DesignWare IP, used in both STM32 and EFM32 chips.
Rename the files to make this more clear, and easier to use in other
targets.
|
|
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.
|
|
This fixes the problem where the first four bytes were skipped in
the fifo.
|
|
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.
|
|
Support for the conflicting bit definitions for vbus sensing on core id
version 0x2000+
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
|
|
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
|
|
ST usbfs-v1, v2, EFM32 USB, lm4f usb all automatically enable the clock
in their _init routine. Do the same for the dwc_otg drivers to be
consistent.
|
|
|
|
This is as per USB 2.0 chapter 9 specifications, and
enables passing of USB-IF Chapter 9 tests.
|
|
|
|
|
|
usbd.h: more comments for bmRequestType and bmAttributes bitfield macros
usbd.h: migrated and added API doxyblocks from implementations (*.c)
|
|
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.
|
|
Only resetting the fifo memory pointers can result in corrupt data.
Tested on f4 disco board with the gadget0 test suite.
|
|
Rather than the index of the config. This happens to be the same
thing if you have zero based sequential configurations.
|
|
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>
|
|
Management of usb code is easier if everything is at one place
|
|
* 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>
|
|
Use the standard REG_BIT name from the reference manuals, as specified
in HACKING All the other bits have the correct naming.
|
|
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
|
|
too many pulls :|
|
|
Otherwise we get 1 kHz of SOF interrupts even if we don't need them.
Originally reported by Uwe in https://github.com/libopencm3/libopencm3/pull/274
but BuFran provided a reworked implementation.
|
