11 Commits

Author SHA1 Message Date
Karl Palsson
42e43515c6 usb gadget0: ctrl write/read loopback tests
This is based on linux's gadget0 intel loopback tests, and also github
pr: https://github.com/libopencm3/libopencm3/pull/592

Note that this captures the currently broken control loopback issues on
dwc_otg devices.

See https://github.com/libopencm3/libopencm3/issues/873 and all linked
issues.

Current status is passing on f3, f0, and failing on f4.
2018-08-27 15:11:32 +00:00
Karl Palsson
144911a25b stm32: usb gadget0: implement loopback
The loopback functionality was never implemented, not for regular bulk
endpoints.  By adding it, and adding pairs of endpoints, we can easily
catch buffer management problems.  These tests currently fail on
st_usbfs devices.

This did require renumbering the endpoints, as dwc_otg_fs only offers
three endpoints in each direction, and they can't be arbitrary numbers,
unlike on st_usbfs.

See https://github.com/libopencm3/libopencm3/pull/880 and related tickets.
2018-08-17 00:16:13 +00:00
Karl Palsson
cbef4a15e4 tests: gadget0: use proper usb enums 2018-03-02 22:42:05 +00:00
Karl Palsson
d97c1b0435 tests: gadget0: delay between calls to trigger races
Attempt to be more brutal by delaying more often, instead of always
promptly servicing the usb stack.

This is implemented via using timer6 to do a known number of
microseconds busy delay, and so only works on platforms that have
reached at least core timer functionality, and provide the
rcc_apb1_frequency variable.

NOTE! This will _fail_ on devices using the st_usbfs drivers at present,
but the code _should_ work, and the tests land to verify that the
library fix, fixes the problem. (see subsequent commit)
2017-06-08 23:01:45 +00:00
fenugrec
c3512f4de5 tests: gadget0: test for unaligned buffer read/writes.
This currently fails on stm32F072, which is expected but not normal.
See GH issues #401 , #461
2016-10-01 15:46:33 +00:00
Karl Palsson
c585336766 tests: gadget0: pull up endpoint size constant 2016-10-01 15:15:36 +00:00
Karl Palsson
ba9cb7dc5d minor stylecheck cleanups 2016-02-29 21:30:31 +00:00
Piotr Esden-Tempski
b1049f9a6f [Style] Stylefix sweep over the whole codebase. 2015-12-14 22:57:15 +01:00
Karl Palsson
3ed12b6fd9 usb: short control IN might need a ZLP
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.
2015-10-11 18:43:11 +00:00
Karl Palsson
52dc61403d tests: gadget0: use proper usb enumerations
Eliminate warnings.  carry over from developing in a different tree.
2015-10-06 01:05:36 +00:00
Karl Palsson
34f00a7d5a tests: usb: gadget0 compatible interface (stm32f4)
This introduces the first firmware setup specifically for automated testing.
Based heavily on the linux kernel project's "USB Gadget Zero" idea, and in
theory, this should be testable with <kernelsrc>/tools/usb/testusb.c but...
not yet.  It's tricky to set that up and poorly documented, so we've got our
own tests instead. Instead, we include a set of python unit tests using pyusb.

These currently only test a basic core subset of functionality, but have already been
very helpful in finding latent bugs.

In this first stage, we support only the stm32f4 disco board, (MB997) and
FullSpeed USB devices.  A generic "rules.mk" is introduced to support multi
platform builds. (See below)

Some basic performance tests are included, but as they take some time to run,
you must manually enable them. See the README for more information

NOTE! Only the source/sink functional interface is supported, loopback will require
some comparision with a real gadget zero to check exactly how it's working.

FOOTNOTES 1:

This introduces a rules.mk file that is arguably substantially simpler[1] for
re-use, and then uses this rules.mk file to support multiple target outputs
from the same shared source tree. Less path requirements are imposed, and less
variables need to be defined in each project's makefile.  A separate bin
directory is created for each project.

All useful settings and configurations imported from the original library rules
file.

cxx support untested, but lifted from the original library rules file.

[1] Than the file in the libopencm3-examples repo it is loosely based on.
2015-10-03 00:58:43 +00:00