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)
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.
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!
Karl Palsson