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.
While on all current chips, exticr gpio port mux selection is coded on 4 bits,
stm32g0 EXTI_EXTICR register uses 8 bits. Align all exti header to reference
that value (was previously defined for f0 as SYCFG_EXTICR_SKIP)
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.
It's always stream on the "new" dma controller (unless it's channel....)
Fix a couple of inconsistent prototypes that had carried over from f1
originally. Reported by vampi on irc.
I2C3 is on many parts, but wasn't properly supported with the register
definitions. Declare them centrally, just depending on the memorymap
defining them. On some parts, the rcc bits were defined, but not the
base registers.
Fixes: https://github.com/libopencm3/libopencm3/issues/820
Just a small typo I came across while trying to get MCO to work on my board.
The define is not used in any other files as far as I can tell, but of
course applications might break if they use the misspelt variant.
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
Move the last few register defines back to their relevant headers, add
doxygen and groups. While these registers _were_ "common" they were the
_only_ common things, so it's simpler for future work (merging f7 with
f2/4) to move them back separately.
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.
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.
