This commit adds initial support for STM32H5xx MCUs. The following
features have been confirmed to be working on an STM32H573:
- UART over REPL and USB CDC
- USB CDC and MSC
- internal flash filesystem
- machine.Pin
- machine.SPI transfers with DMA
- machine.ADC
- machine.RTC
- pyb.LED
- pyb.Switch
- pyb.rng
- mboot
Signed-off-by: Damien George <damien@micropython.org>
Instead of being an explicit field, it's now a slot like all the other
methods.
This is a marginal code size improvement because most types have a make_new
(100/138 on PYBV11), however it improves consistency in how types are
declared, removing the special case for make_new.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This also fixes a possible race condition when exiting initialisation mode:
reading then writing to ISR (via ISR &= ~RTC_ISR_INIT) will clear any flags
that were set by the hardware between the read and the write. The correct
way to clear just the INIT bit is to just do a single write via ISR =
~RTC_ISR_INIT, which will not clear any other flags (they must be written
to 0 to clear), and that is exactly what LL_RTC_DisableInitMode does.
Signed-off-by: Damien George <damien@micropython.org>
This commit adds support for the STM32G4 series of MCUs, and a board
definition for NUCLEO_G474RE. This board has the REPL on LPUART1 which is
connected to the on-board ST-link USB-UART.
This commit is based upon prior work of @dpgeorge and @koendv.
MCU support for the STM32H7A3 and B3 families MCUs:
- STM32H7A3xx
- STM32H7A3xxQ (SMPS)
- STM32H7B3xx
- STM32H7B3xxQ (SMPS)
Support has been added for the STM32H7B3I_DK board.
Signed-off-by: Jan Staal <info@janstaal.com>
Devices with RTC backup-batteries have been shown (very rarely) to have
incorrect RTC prescaler values. Such incorrect values mean the RTC counts
fast or slow, and will be wrong forever if the power/backup-battery is
always present.
This commit detects such a state at start up (hard reset) and corrects it
by reconfiguring the RTC prescaler values.
Signed-off-by: Damien George <damien@micropython.org>
For time-based functions that work with absolute time there is the need for
an Epoch, to set the zero-point at which the absolute time starts counting.
Such functions include time.time() and filesystem stat return values. And
different ports may use a different Epoch.
To make it clearer what functions use the Epoch (whatever it may be), and
make the ports more consistent with their use of the Epoch, this commit
renames all Epoch related functions to include the word "epoch" in their
name (and remove references to "2000").
Along with this rename, the following things have changed:
- mp_hal_time_ns() is now specified to return the number of nanoseconds
since the Epoch, rather than since 1970 (but since this is an internal
function it doesn't change anything for the user).
- littlefs timestamps on the esp8266 have been fixed (they were previously
off by 30 years in nanoseconds).
Otherwise, there is no functional change made by this commit.
Signed-off-by: Damien George <damien@micropython.org>
Note: the uncrustify configuration is explicitly set to 'add' instead of
'force' in order not to alter the comments which use extra spaces after //
as a means of indenting text for clarity.
This new series of MCUs is similar to the L4 series with an additional
Cortex-M0 coprocessor. The firmware for the wireless stack must be managed
separately and MicroPython does not currently interface to it. Supported
features so far include: RTC, UART, USB, internal flash filesystem.
If MICROPY_HW_RTC_USE_BYPASS is enabled the RTC startup goes as follows:
- RTC is started with LSE in bypass mode to begin with
- if that fails to start (after a given timeout) then LSE is reconfigured
in non-bypass
- if that fails to start then RTC is switched to LSI
It can be that LSEON and LSERDY are set yet the RTC is not enabled (this
can happen for example when coming out of the ST DFU mode on an F405 with
the RTC not previously initialised). In such a case the RTC is never
started because the code thinks it's already running. This patch fixes
this case by always checking if RTCEN is set when booting up (and also
testing for a valid RTCSEL value in the case of using an LSE).
With this and previous patches the stm32 port can now be compiled using
object representation D (nan boxing). Note that native code and frozen mpy
files with float constants are currently not supported with this object
representation.
For a given IRQn (eg UART) there's no need to carry around both a PRI and
SUBPRI value (eg IRQ_PRI_UART, IRQ_SUBPRI_UART). Instead, the IRQ_PRI_UART
value has been changed in this patch to be the encoded hardware value,
using NVIC_EncodePriority. This way the NVIC_SetPriority function can be
used directly, instead of going through HAL_NVIC_SetPriority which must do
extra processing to encode the PRI+SUBPRI.
For a priority grouping of 4 (4 bits for preempt priority, 0 bits for the
sub-priority), which is used in the stm32 port, the IRQ_PRI_xxx constants
remain unchanged in their value.
This patch also "fixes" the use of raise_irq_pri() which should be passed
the encoded value (but as mentioned above the unencoded value is the same
as the encoded value for priority grouping 4, so there was no bug from this
error).
The CMSIS files for the STM32 range provide macros to distinguish between
the different MCU series: STM32F4, STM32F7, STM32H7, STM32L4, etc. Prefer
to use these instead of custom ones.
Newer versions of the HAL use names which are cleaner and more
self-consistent amongst the HAL itself. This patch switches to use those
names in most places so it is easier to update the HAL in the future.
Upon boot the RTC early-init function should detect if LSE or LSI is
already selected/running and, if so, use it. When the LSI has previously
(in the previous reset cycle) been selected as the clock source the only
way to reliably tell is if the RTCSEL bits of the RCC_BDCR are set to the
correct LSI value. In particular the RCC_CSR bits for LSI control do not
indicate if the LSI is ready even if it is selected.
This patch removes the check on the RCC_CSR bits for the LSI being on and
ready and only uses the check on the RCC_BDCR to see if the LSI should be
used straightaway. This was tested on a PYBLITEv1.0 and with the patch the
LSI persists correctly as the RTC source as long as the backup domain
remains powered.
Previously, if LSE is selected but fails and the RTC falls back to LSI,
then the rtc_info flags would incorrectly state that LSE is used. This
patch fixes that by setting the bit in rtc_info only after the clock is
ready.
This is to keep the top-level directory clean, to make it clear what is
core and what is a port, and to allow the repository to grow with new ports
in a sustainable way.
