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.
Fixes https://github.com/libopencm3/libopencm3/issues/476
Sets USB_COUNTn_RX reg fields : bits <14:10> are NUM_BLOCK; bit 15 is BL_SIZE.
- When (size <= 62), BL_SIZE must be 0 and NUM_BLOCK set to (size / 2).
- When (size > 62), BL_SIZE must be 1 and NUM_BLOCK=((size / 32) - 1).
Previous code improperly set NUM_BLOCK and assumed the requested size was set.
Now, we use the next largest legal buffer size. Examples:
size BL_SIZE NUM_BLOCK => Actual bufsize
0 0 0 ??? (illegal !)
1 0 1 2
63 1 1 64
Algo is valid for F102, F103 and F0 devices (USB_FS peripheral).
In addition, the new usb_set_ep_rx_bufsize() function returns the actual
size set.
Tested-by: Karl Palsson <karlp@tweak.net.au>
LPUART1 needs BRR to be 256 times the normal value.
Doing this with 64 bit math would work, but that pulls in quite a lot of
code for every platform, even if they don't have LPUART.
A little bit of maths, thanks to zyp on irc, lets us keep it in 32bit,
provided people don't try and use > 16MBaud on LPUARTs
Originally tracked via https://github.com/libopencm3/libopencm3/pull/888
This shows what is _actually_ different for f7. A couple of option
bits, and a renaming of bit 7 of the status register, from Program
Sequence Error to Erase Sequence Error.
We keep the separate implementation of wait_for_last_operation, to meet
the "suggestions" of the reference manual to insert a DSB instruction.
Keeping the renamed bit/functions also requires us to keep separate
implementations of the flag clearing functions
F3's flash interface is actually quite different, don't try and force
sharing code that isn't really related. The "PGERR" is a very different
bit than the parallelism error that f2/4/7 have.
Comments were not consistent, and this serves no purpose. There's no
reason to explicitly lock the flash first before unlocking. These bits
are simply set when the keys are written.
All the "f" type flash parts have an EOP flag, even if it's in different
bit positions. Add a header for this common functionality, and move
it's implementation to the existing common file.
Turns out, there's lots of common code for flash. Pull up prefetch
on/off to start with, as there's only a single bit name different.
Pull up the definitions of common API functions too, starting with
flash_set_ws. Even if the implementations are different, things that
meant to be the same, should be defined centrally.
The sector list is numerically contiguous, but the bits to write are not
contiguous. Good job ST.
Fixes: https://github.com/libopencm3/libopencm3/pull/934
Don't see any reason to make public definitions of these sorts of magic
numbers, they're completely internal to sector addressing.
- Change .power_save to .voltage_scale, a pwr_vos_scale enum
- Enable pwr clock before setting VOS scale
- Fix flash wait states
- Make flash_set_ws more robust
We didn't actually mark it deprecated very well, but it was
non-functional, and simply a poorly implemented wrapper for
rcc_periph_reset_pulse() anyway.
It's now been obsoleted in the examples for more than a year, and it's
time to kill it outright.
Fixes: https://github.com/libopencm3/libopencm3/issues/709
Only applied to STM32 doc trees at present.
Instead of declaring a group for "STM32blah" in the doc-blah.h files,
and then trying to put all the common+specific peripheral code into
those groups, (which is what led to the stub doxygen holder empty .c
files) Just use a standard name like "Peripheral APIS" and place
everything into that.
Demonstrated by converting ADC and USART peripherals, which is
definitely not complete, but it shows how to make things less magical,
and less prone to copy/paste errors. Now, you can copy/paste and it
will do the right thing, because everyone uses the same group names.
This is also how to unify the mix of "STM32blah->Periphblah" and _also_
the dangling "periph_file" modules in doxygen, it merges them together
properly, as they're intended to be really.
split spi stuff in three part:
- v1 : basic spi peripheral
- v1_frf : v1 spi with frf mode additional bit in spi_cr2 / spi_sr
- v2 : spi with variable datasize, fifo and other fancy stuff.
v1 maps to f1 chips
v1_frf to f2, f4 and l0,l1
v2 to f0, f3 and l4
This breaks spi_master_init API for v2 devices : function prototype from
common spi header used to be abused, with DFF bit reused for CRCL bit.
New v2 spi_master_init does not handle anymore CRCL bits, as it does not
usually mess with other crc configuration.
The ADC v2 peripheral doesn't have the same behaviour of starting, where
the hardware clears the bit immediately, on v2, it is not cleared until
the ADC is stopped, or the end of sequence flag is set.
Fixes https://github.com/libopencm3/libopencm3/issues/557
The SPI br parameter has always been the 3 bit fpclk divider field, and
was never a target or explicit bit rate. Correct the comments, and drop
the duplicate commentary that wasn't included in the doxygen output
anyway.
Fixes: a7a3770d Add initial SPI code
This function was using apb1 for quite a few families instead of apb2.
This only mattered for L1 and F3, and for USART1/USART6, and only if
apb1 speed != apb2 speed.
Instead of using families explicitly, just check for the peripherals
themselves. On F0,F1,F2,F3,F4,F7,H7,L0,L1,L4, usart1/6 are _always_ in
the rcc_apb2 register and the other uarts are all on apb1.
(F0 doesn't actually _have_ apb2, but it's still called the apb2
register)
The ADVANCED_TIMERS define/check was added in 523943a as part of adding L1
support. The runtime checks against TIM1/TIM8 already existed. Since L1
doesn't have TIM1/TIM8, those names are undefined, resulting in a compilation
error until ifdeffed out.
Since I throw out all TIM1/TIM8 checks, there's no references to those names
left, thus no need to keep the ifdef either.
As for the registers themselves, l1/timer.h pulls in common/timer_common_all.h
which defines macros for the superset of all timers, so e.g. TIM_BDTR() is
still available regardless of whether or not the particular chip we're building
for has any timers with a BDTR register.
rcc_osc_bypass_enable and rcc_osc_bypass_disable have been copy/pasted
around for the last time! There's a compile bit to check for L0/L1, but
otherwise this is just code duplication for no gain.
For both v1 and v2, provide routines to help do arbitrary length
write/read transfers.
Tested with multiple byte writes and reads, for both 100khz and 400khz,
with repeated starts and stop/starts. However, only tested (presently)
with a single i2c target device, a Sensiron SHT21 sensor. Extended
testing against eeproms and alternative devices would be useful
