More could probably be found, but this makes some of the basic RCC defines for
the L0 much more inline with other platforms, and much less verbose. This
helps us have more identical code for library users across different targets.
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.
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>
By adding an "eep" memory section, and a NOLOAD step into the linker
scripts, you can now let gcc allocate variables in eeprom for you.
However, as fitting for eeprom, they cannot be initialized, and will not
be loaded at any time. This simply lets you get place variables in the
eeprom space.
Example:
struct whatever __attribute__((section(".eeprom"))) blah;
struct another __attribute__((section(".eeprom"))) wop;
printf("%#x", &blah); // ==> 0x08080000
printf("%#x", &wop); // ==> 0x08080000 + sizeof(blah)
You can read directly out of these variables, but need to use the
eeprom_ routines for writing to them.
Correct memory sizes in ld/devices.data for:
* stm32f3[01]3?c from RAM=48K to RAM=40K.
* stm32f303?b from RAM=40K to RAM=32K.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
We haven't yet moved everything over to any autogenerated linker scripts, so
include more common templates instead of proliferating mountains of them in
every example.
* 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>
The MPU is an implementation option available for both ARMv6-M and ARMv7-M.
Remove poorly merged code that attempted to include this only for cortex m0+.
Added doxygen, updated the definitions of the RBAR register, (though if you're
really using this periperhal, you should be looking at the ref man for further
information)
Reported-by: forrestv on irc.
SCB.CCR.STKALIGN enables the automatic aligning of the stack pointer to 8 bytes
on interrupt entry. Per ARM recommendations, and for AAPCS compliance, this
bit should be enabled at all times. ARMv6M has this hardcoded to 1. Cortex M3
has this broken in rev 0, optional (default off) in rev 1, and optional
(default on) in rev 2 and later. M4(f) has optional (default on) for all
revisions, M7 has hardcoded to 1.
See Section 2.3.3 in ARM document IHI0046B:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0046b/IHI0046B_ABI_Advisory_1.pdf
To ensure that all parts behave correctly, we make sure that we hardcode the
feature on, for all parts. While not _required_ for anything other than rev1
cm3, inserting it into the common reset handler ensures no-one gets any
surprises.
Fixes Github issue #516
All STM32 family pwr.h must use LIBOPENCM3_PWR_H as include guard so that
pwr_common.h can detect that it has been referenced by pwr.h for
each family. F2 and F3 had the wrong include guard.
Fixes Github issue #513
The existing rcc_clock_setup_pll only allowed HSI as the clock source, even
though the existing clock structure contains pll source variables.
Check this value, and switch to the corresponding clock source, rather than
blindly assuming that we are tryign to operate from HSI.
(probably because the Ref Manual erroneously required it).
This has a naughty side-effect in that unrelated user data in the BD would be wiped.
Replaced this call by clearing the RTC registers to their default values.
Tested with ET-STAMP-STM32 to verify RTC starts from power-on and reset with expected behaviour.
This removes the shift from the defines, and includes them in the helper
function, making the code match the documentation, and following how the
rest of the library commonly operates.
Code using the existing defines will continue to work.
Basic helpers to at least support common configurations for the f401.
Original submission specified 5 wait states, but the reference manual and other
reviewers all believe that 2ws is sufficient for these modes.
Signed-off-by: Karl Palsson <karlp@tweak.net.au>
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.
The f3 adc has separate bits for end of conversion and end of sequence.
Support those fully, with the regular enable/disable irq methods, and
the flag checking methods.
Discovered in github bug: #493
This code was copied from the f4, and blindly modified to make it seem
to work. The f3 has separate flags for EOC and EOS, it doesn't use a
second bit to configure what the EOC bit does.
Consequently, update the documentation to correctly indicate that the
EOC bits are only set per conversion.
Discovered in github bug: #493
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
