GD32F1X0 (X can be 3, 5, 7 and 9) is a series of Cortex-M3 MCUs by
GigaDevice, which features pin-to-pin package compatibility with
STM32F030 MCU line. F150 adds USB support to F130, and F170/F190 adds
CAN support.
Currently the code mainly targets GD32F130 and F150 chips. Some register
are different between F130/150 and F170/190, just like the difference
between STM32F1 Performance line and Connectivity line.
From the perspective of registers and memory map, GD32F1X0 seems like a
mixture between STM32F1 and STM32F0 (because it is designed to be
pin-to-pin compatible with F0, but with Cortex-M3 like F1). A bunch of
code are shared between STM32 and GD32, and these code are specially
processed to include the GD32 headers instead of STM32 headers when meet
GD32F1X0.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
gd32/rcc.[ch] are forks of stm32f1/rcc
gd32/flash.[ch] are forks of stm32f0/flash
No attempts at deduplicating this have been done at this stage. We can
see where they move in the future.
Make exti_get_flag_status and exti_reset_request use EXTI_RPR and EXTI_FPR if present instead of EXTI_PR.
This is less precise than offered by the RPR/FPR registers, but makes
for a consistent experience in the common API.
Reviewed-by: Karl Palsson <karlp@tweak.net.au>
EXTICR on stm32g0 is in exti registers range. Previous chips used to have that
gpio port exti mux configuration accessible via AFIO_EXTICR or SYSCFG_EXTICR.
Also, the new chip now use 8 bits coded value instead of previously 4 for the
extcr mux selection value (see AFIO/SYSCFG/EXTI_EXTICR_FIELDSIZE)
Let's define two helpers: EXTICR_SELECTION_REG (to get proper AFIO/SYSCFG/
EXTI_EXTICR register) and EXTICR_SELECTION_FIELDSIZE (to get proper AFIO/SYSCFG/
EXTI_EXTICR_FIELDSIZE value), and use it them exti_select_source to determine
exticr mux selection bits shift and mask.
flash_unlock_acr allows to unlock RUN_PD bit from FLASH_ACR register. Relock is done automatically
when writing 0 to RUN_PD, so no flash_lock_acr method.
the 2014q3 or later toolchains are now readily available, and we should
now just consider this a user problem. This gets us out of trying to
parse compiler help output and chasing our own tail.
Fixes https://github.com/libopencm3/libopencm3/issues/965
They were originally used to make sure that the doxygen was generated
correctly, but that style is no longer necessary.
There may be more peripherals that can be "cleaned" like this, but let's
do them one step at a time, as we work on that area.
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.
usb_disconnect() is board/platform specific for chips that don't have
built-in handling for this. Allow the application to provide its own
version of usb_disconnect() to handle this.
See https://github.com/libopencm3/libopencm3/pull/924
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
We extracted code out to the common files, but they weren't being
linked. This didn't matter in the past, as they were empty.
Fixes: 46d4103c stm32: flash: move wait_for_last to f2/f4 explicitly.
Fixes: https://github.com/libopencm3/libopencm3/issues/953
flash_clear_pgperr_flag is a name used on f247, which is actually most
analogous to the SIZERR bit on l4, (it's a parallelism error)
the bit being cleared originally in this function, PROGERR is a new bit,
and should have it's own name.
Add a function to handle the previously unhandled size/parallelism flag,
and rename the existing one to properly reflect it's new name.
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.
l4 is pages, not sectors, so update apis to be consistent. (other
families use page/sector as defined in the reference manual)
Make sure that pages on the second bank can also be erased. Use the
same style in use for f2/4/7 for sector numbers across banks.
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.
Ross Schlaikjer