A board can now use BUILDING_MBOOT at the Makefile-level to do things
conditional on building mboot, for example add source files to SRC_C.
Signed-off-by: Damien George <damien@micropython.org>
Commit 1e297c8898 introduced a bug where the
very first reset-mode state on the LEDs was not shown, because prior to
that commit the first reset-mode state was the same as the initial LED
state (green on, others off) and update_reset_mode() was called after
setting this initial LED state.
This is fixed in this commit by changing the update_reset_mode() loop so
that it displays the current reset mode before doing the delay.
Signed-off-by: Damien George <damien@micropython.org>
And use the same boardctrl.h header for both the application and mboot so
these constants are consistent.
Signed-off-by: Damien George <damien@micropython.org>
This adds support for making static (ie not on the Python GC heap) soft
timers. This can be useful for a board to define a custom background
handler, or eventually for BLE/network processing to use instead of systick
slots; it will be more efficient using soft timer for this.
The main issue with using the existing code for static soft timers is that
it would combine heap allocated and statically allocated soft_timer_entry_t
instances in the same pairing-heap data structure. This would prevent the
GC from tracing some of the heap allocated entries (because the GC won't
follow pointers outside the heap).
This commit makes it so that soft timer entries are explicitly marked,
instead of relying on implicit marking by having the root of the pairing
heap in the root pointer section. Also, on soft reset only the heap-
allocated soft timers are deleted from the pairing heap, leaving the
statically allocated ones.
Signed-off-by: Damien George <damien@micropython.org>
Improvements are:
- Default period is 1000ms with callback disabled.
- if period is not specified then it's not updated (previously, if period
was not specified then it was set to -1 and running the timer callback as
fast as possible, making the REPL unresponsive).
- Use uint64_t to compute delta_ms, and raise a ValueError if the period is
too large.
- If callback is not specified then it's not updated.
- Specifying None for the callback will disable the timer.
Signed-off-by: Damien George <damien@micropython.org>
This function includes the UART prescaler in the calculation (if it has
one, eg on H7 and WB MCUs).
Signed-off-by: Damien George <damien@micropython.org>
The STM32WB has a problem when address resolution is enabled: under certain
conditions the MCU can get into a state where it draws an additional 10mA
or so and eventually ends up with a broken BLE RX path in the silicon. A
simple way to reproduce this is to enable address resolution (which is the
default for NimBLE) and start the device advertising. If there is enough
BLE activity in the vicinity then the device will at some point enter the
bad state and, if left long enough, will have permanent BLE RX damage.
STMicroelectronics are aware of this issue. The only known workaround at
this stage is to not enable address resolution, which is implemented by
this commit.
Work done in collaboration with Jim Mussared aka @jimmo.
Signed-off-by: Damien George <damien@micropython.org>
Prior to this commit, if C2 was busy (eg lots of BLE activity) then it may
not have had time to respond to the notification on the IPCC_CH_MM channel
by the time additional memory was available to put on that buffer. In such
a case C1 would modify the free buffer list while C2 was potentially
accessing it, and this would eventually lead to lost memory buffers (or a
corrupt linked list). If all buffers become lost then ACL packets
(asynchronous events) can no longer be delivered from C2 to C1.
This commit fixes this issue by waiting for C2 to indicate that it has
finished using the free buffer list.
Work done in collaboration with Jim Mussared aka @jimmo.
Signed-off-by: Damien George <damien@micropython.org>
STM32L476RG MCU of NUCLEO_L476RG board has 6 UART/USART units in total
(USART1, USART2, USART3, UART4, UART5 and LPUART1), but only UART2,
connected to REPL, was defined and available in Python code.
Defined are all 5 remaining UART/USART units including LPUART1.
Signed-off-by: Alexander Ziubin aziubin@googlemail.com
This commit simplifies the customisation of the main MicroPython execution
loop (4 macros are reduced to 2), and allows a board to have full control
over the execution (or not) of boot.py and main.py.
For boards that use the default start-up code, there is no functional
change in this commit.
Signed-off-by: Damien George <damien@micropython.org>
Support for C++ was added in 97960dc7de but
that commit didn't include the C++ exception handling table in the binary
firmware image. This commit fixes that.
Signed-off-by: Damien George <damien@micropython.org>
The GNU Make dir command uses spaces as item separator so it does not
work for e.g building the STM32 port on Cygwin with a default Arm
installation in "c:/program files (x86)/GNU Arm Embedded Toolchain".
Fix by using POSIX dirname on a quoted path instead.
This allows the user to enable wake-up sources using the EWUP bits, on F7
MCUs.
Disabling the wake-up sources while clearing the wake-up flags follows the
reference manual and ST examples.
state.reset_mode is updated by `MICROPY_BOARD_BEFORE_SOFT_RESET_LOOP` but
not passed to `init_flash_fs`, and so factory reset is not executed on
boards that do not have a bootloader. This bug was introduced by
4c3976bbcaFixes#6903.
A corrupt filesystem may lead to a request for a block which is out of
range of the block device limits. Return an error instead of passing the
request down to the lower layer.
Two of the defaults have also changed in this commit:
- MICROPY_HW_RFCORE_BLE_LSE_SOURCE changed from 1 to 0, which configures
the LsSource to be LSE (needed due to errata 2.2.1).
- MICROPY_HW_RFCORE_BLE_VITERBI_MODE changed from 0 to 1, which enables
Viterbi mode, following all the ST examples.
Signed-off-by: Damien George <damien@micropython.org>
These ports already have uzlib enabled so this additional ubinascii.crc32
function only costs about 90 bytes of flash.
Signed-off-by: Damien George <damien@micropython.org>
Add LPUART1 as a standard UART. No low power features are supported, yet.
LPUART1 is enabled as the next available UART after the standard U(S)ARTs:
STM32WB: LPUART1 = UART(2)
STM32L0: LPUART1 = UART(6)
STM32L4: LPUART1 = UART(6)
STM32H7: LPUART1 = UART(9)
On all ports: LPUART1 = machine.UART('LP1')
LPUART1 is enabled by defining MICROPY_HW_LPUART1_TX and
MICROPY_HW_LPUART1_RX in mpconfigboard.h.
Signed-off-by: Chris Mason <c.mason@inchipdesign.com.au>
So that mboot can be used to program encrypted/signed firmware to regions
of flash that are not the main application, eg that are the filesystem.
Signed-off-by: Damien George <damien@micropython.org>
The default for these is to enable them, but they can now be disabled
individually by a board configuration.
Signed-off-by: Damien George <damien@micropython.org>
If a board defines USBD_VID then that will be used instead of the default.
And then the board must also define all USBD_PID_xxx values that it needs.
Signed-off-by: Damien George <damien@micropython.org>
This allows changing the baudrate of the UART without reinitialising it
(reinitialising can lead to spurious characters sent on the TX line).
Signed-off-by: Damien George <damien@micropython.org>
To simplify config, there's no need to specify MP_PLAT_PRINT_STRN if it's
the same as the default definition in py/mpconfig.h.
Signed-off-by: Damien George <damien@micropython.org>
With mboot encrpytion and fsload enabled, the DEBUG build -O0 compiler
settings result in mboot no longer fitting in the 32k sector. This commit
changes this to -Og which also brings it into line with the regular stm32
build.
MCUs with device-only USB peripherals (eg L0, WB) do not implement (at
least not in the ST HAL) the HAL_PCD_DisconnectCallback event. So if a USB
cable is disconnected the USB driver does not deinitialise itself
(usbd_cdc_deinit is not called) and the CDC driver can stay in the
USBD_CDC_CONNECT_STATE_CONNECTED state. Then if the USB was attached to
the REPL, output can become very slow waiting in usbd_cdc_tx_always for
500ms for each character.
The disconnect event is not implemented on these MCUs but the suspend event
is. And in the situation where the USB cable is disconnected the suspend
event is raised because SOF packets are no longer received.
The issue of very slow output on these MCUs is fixed in this commit (really
worked around) by adding a check in usbd_cdc_tx_always to see if the USB
device state is suspended, and, if so, breaking out of the 500ms wait loop.
This should also help all MCUs for a real USB suspend.
A proper fix for MCUs with device-only USB would be to implement or somehow
synthesise the HAL_PCD_DisconnectCallback event.
See issue #6672.
Signed-off-by: Damien George <damien@micropython.org>
Don't clear the IPCC channel flag until we've actually handled the incoming
data, or else the wireless firmware may clobber the IPCC buffer if more
data arrives. This requires masking the IRQ until the data is handled.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
It's enabled by default to retain the existing behaviour. A board can
disable this option if it manages mounting the filesystem itself, for
example in frozen code.
Signed-off-by: Damien George <damien@micropython.org>
Damien George
iabdalkader
plan-do-break-fix
David Michieli
8bitgeek
aziubin
stijn
Reinhard Feger
Peter Hinch
Braiden Kindt
Herwin Grobben
Andrew Leech
Chris Mason
Andrew Leech
Andrew Scheller
Jim Mussared