libopencm3
Add stm32u5 support
What is it about?
Basing on STM family microcontroller stm32u585 I would like to extend the libopencm3 with support for new ARM M33 core. My development focus on the most crucial parts of the u585 chip. Not all features I am able to fully test in the board, therefore I would suggest to intake this as fundament for latter extension.
Currently, implemented
All tests done on B-U585I-IOT02A discovery board.
- Memory map based on the reference documentation
- Linker generation
- Makefile targets for u5 family
- Add GPIO and RCC
- Tested by: blinking LED on port H pin 7 and 6
- Add simple clock setup
- set system clock based on passed structure
- set system clock as HSI16
- Tested with: HSI16 and default setup
- Add USART support
- Tested by: Rx/Tx 8N1 on USART2 with different clock source and system clock setting.
- Tested by: Running Rx mode with IRQ
- Add I2C support
- Tested by: Running I2C2 on 16MHz HSI in master mode.
- Tested SysTick
- Added NVIC module and tested with sample IRQs
- Added IWDT + added early wakeup support
- Added EXTI support
- Added EXTI module, tested with user button (rising and falling) on EXTI13
- Added Timer module
- Tested with TIM2 + IRQ standard count up
I pulled this pr and built it, what is there works on my Nucleo board. That said, what I was looking for was the STM32U5G support which is same family but everything is bigger. In particular it has 4MB of flash, and 3024K of RAM which appears at two places in memory depending on whether or not you want it "secure" or not. So there is a style question here.
You can say RAM=3024K in the device bits, but the RAM offset appears to be 0x0a000000 rather than 0x20000000. In the reference manual it shows 0x20000000 - 0x40000000 to before 'external' memories (that is to say mapped to either QSPI or the FMC). Still feeling my way around this thing. But a question for @karlp which is would you prefer a 'family' device section that groups all STM325U devices in one group, or would you prefer two groups as the RAM offset at least has to be changed for the U5G variant.
I'm not reviewing anything. I've tried making that clear, but people like to keep tagging me anyway. Speak to one of the other maintainers.
@ChuckM It depends on how it technically will work out. I guess it might be easier to actually split the group into two sets. Unless it ends up being easier to just add an extra compile time define to switch between the two groups. Not 100% sure what ergonomics make more sense here.
