| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This helps catch some perhaps unintended api changes
|
|
Fixes: ec1d2855b stm32l1: rcc: use better naming for flash wait states
|
|
|
|
D+ is PA12 not PA11. The reason this worked before, is because the line
before made PA12 output, and without setting the GPIO_ODR register
_before_ hand, this meant as soon as it was switched to output, it
received the reset value of GPIO_ODR for PA12, ie, 0. (Effectively
doing a "free" gpio_clear(GPIOA, GPIO12)
Because GPIO11 wasn't configured to be an output, the confusing
gpio_clear(GPIOA, GPIO11) was simply configuring the pullup/down value
of the input, which was still ignored, as it was (out of reset) in input
floating mode.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
|
|
|
|
|
|
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)
|
|
Doesn't actually change the test results, but gets more coverage from
the same test case.
|
|
Less command line arguments, more automatic "do what I mean"
|
|
Connect to an existing and pass the correct path name.
|
|
Easier than editing the file each time.
|
|
Drop unnecessary ; in python
|
|
|
|
No real changes.
|
|
This currently fails on stm32F072, which is expected but not normal.
See GH issues #401 , #461
|
|
|
|
Fixes Github issue #652
|
|
|
|
Instead of having committed files containing a single developer's serials, use
optional includes to include a local config file for each board.
If you have only a single board connected, simply:
$ make -f Makefile.<board> clean all flash
If you have multiple boards connected, make sure to fill in the appropriate
hla_serial in your openocd.<board>.local.cfg file, and then run the same
commands.
|
|
|
|
See
https://docs.python.org/2/library/unittest.html#unittest.TestCase.longMessage
Allows showing the 42 != 69 : custom message instead of _only_ showing the
custom message if one was specified.
|
|
|
|
The F429i board has the user USB OTG port connected to the HS capable
OTG core, rather than the FS OTG core. It is still only operating in FS
mode, as you need a ULPI phy to use HS mode.
|
|
Fixes: 3a7cbec776bc9b9b53eefc26d5bf365466977e5a
|
|
|
|
As recently added to the library, allow the tests to be compiled with user
overridable flags too
|
|
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.
|
|
Don't commit commented out code! bad!
|
|
Eliminate warnings. carry over from developing in a different tree.
|
|
Much more complicated clock setup, but tests all pass once you get past that
step.
|
|
* Only the L1 needed to include flash settings
* whitespace and comment cleanup
* drop redundant clock setting calls
|
|
Based on previous work, add a new driver for the v2 usb peripheral found on
stm32f0 and l0 devices.
Correspondingly, add a usb gadget zero test suite for the f0. L0 device level
code isn't yet ready, but will add the test case when it moves in.
Work by Frantisek Burian, Kuldeep
Singh Dhaka, Robin Kreis, fenugrec and zyp on irc, and all those forgotten.
|
|
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.
|
|
As with F103 generic, there's no readily available L1 board with USB device
A custom LED is used to track boot process, but otherwise this should be
portable to any L1 board, except for the openocd configuration file.
Tests pass straight away, which is good, as it uses the existing f103 usb
driver.
|
|
There's no F1 discovery style board with usb device, so this is for a "generic"
device. The USB portion should be safe, but there's a led used for bootup that
is board specific, and of course the clock source is board specific.
Related, the openocd config file is rather custom to my own setup, but shows
what you need to customize for your test environment.
Further, as the F1 usb core doesn't include support for soft disconnect, use
the very hacky method of dragging the pin low to force reenumeration on reset.
Very very useful for development purposes!
|
|
If you can read this, you're not using a version control system affected by
this change ;)
Before: make -d | wc -l ==> 992
After: make -d | wc -l ==> 452
|
|
Instead of just adding elf/bin and friends, actively delete the original
suffixes and include only things we care about.
Before vs After:
make -d | wc -l ==> 4497
make -d | wc -l ==> 932
Now, if only I could turn off the RCS/SCCS support so easily.
|
|
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.
|
