Since the very beginning, the stm32 port (first called stm, then stmhal now
stm32) has had a special keyboard interrupt feature which works by using
PendSV to break out of any running code. This preemptive ctrl-C was added
long ago in commit 01156d510c.
The stm32 port still uses that code, and current does this:
- If ctrl-C is received on UART or USB then `mp_sched_keyboard_interrupt()`
is called (like all other ports) to set a flag for the VM to see, and
then the VM (or any loop calling `mp_handle_pending(true)`) will
eventually handle the `KeyboardInterrupt` exception, raising it via NLR.
- If another ctrl-C is received while the existing scheduled keyboard
interrupt is still pending (ie the VM has not yet processed it) then a
special hard NLR jump will activate, that preempts the calling code.
Within the PendSV interrupt the stack is adjusted and an NLR jump is made
to the most recent `nlr_push()` location. This is like a normal NLR
except it is called from an interrupt context and completely annihilates
the code that was interrupted by the IRQ.
The reason for the preemptive interrupt was to handle ctrl-C before the VM
was able to handle it. Eventually a mechanism (that's in use today by all
ports) was added to the VM and runtime to be able to check for pending
interrupts. Then the stm32 port was updated to use this mechanism, with a
fallback to the old preemptive way if a second ctrl-C was received (without
the first one being processed).
This preemptive NLR jump is problematic because it can interrupt
long-running instructions (eg store multiple, usually used at the end of a
function to restore registers and return). If such an instruction is
interrupted the CPU remembers that with some flags, and can resume the
long-running instruction when the interrupt finishes. But the preemptive
NLR does a long jump to different code at thread level and so the
long-running interrupt is never resumed. This leads to a CPU fault.
This fault has been previously reported in issues #3807 and #3842 (see also
issue #294). It's now possible to easily reproduce this problem, since
commit 69c25ea865. Running the test suite
over and over again on any stm32 board will eventually crash the board (it
can happen on a PYBv1.x, but it happens more regularly on PYBD-SF2/6).
The point is, a skipped test now soft resets the board and so the board
must run `boot.py` again. The test runner may then interrupt the execution
of `boot.py` with the double-ctrl-C that it sends (in `tools/pyboard.py`,
`enter_raw_repl()`) in order to get the board into a known good state for
the next test. If the timing is right, this can trigger the preemptive
PendSV in an unfortunate location and hard fault the board.
The fix in this commit is to just remove the preemptive NLR jump feature.
No other port has this feature and it's not needed, ctrl-C works very well
on those ports. Preemptive NLR jump is a very dangerous thing (eg it may
interrupt and break out of an external SPI flash operation when reading
code from a filesystem) and is obviously buggy.
With this commit, stm32 borads no longer hard fault when running the test
suite (but it does leave an issue, the tests can still interrupt `boot.py`
with a single ctrl-C; that will be fixed separately).
An alternative to this commit would be to clear the CPU state for the
long-running instruction as suggested in issue #3842. But it's much
simpler to just remove this code, which is now unnecessary and can have
other problems as per issue #294.
Signed-off-by: Damien George <damien@micropython.org>
lwIP was recently updated in a89ac9e24a
to STABLE-2_2_0_RELEASE, and this introduced a change in the configuration
variable `DHCP_DOES_ARP_CHECK`, renaming it to `LWIP_DHCP_DOES_ACD_CHECK`.
This commit fixes the ports lwIP settings to use the new configuration
option.
Without this option, connecting to a WiFi access-point takes about 12.5
seconds. With this option (ie disabling DHCP ARP checks) connecting takes
about 4 seconds.
Tested on an RPI_PICO_W and PYBD_SF2.
Signed-off-by: Damien George <damien@micropython.org>
The UART driver enables a pull-up on RX/CTS pins by default. This can
cause UART to fail to receive in certain situations, eg with RS485
transceivers.
This commit adds compile-time configuration options to set the pull mode on
the RX and CTS pins of each UART.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
The STM32F429DISC board definition did not have DAC enabled, however the
micro/board supports it so this commit enables the feature.
Signed-off-by: Matt Trentini <matt.trentini@gmail.com>
Allows mpremote file transfer to work correctly when mpremote is used over
the ST-link USB/UART REPL port.
Fixes issue #8386.
Signed-off-by: Andrew Leech <andrew.leech@planetinnovation.com.au>
This allows UART RX to function while flash erase/writes operations are
under way, preventing lost serial data so long as it fits in the UART RX
buffer.
This enables (among other things) mpremote to successfully copy files to
boards that use a UART REPL.
Enable via the following option placed in `mpconfigboard.mk`:
MICROPY_HW_ENABLE_ISR_UART_FLASH_FUNCS_IN_RAM = 1
Signed-off-by: Andrew Leech <andrew.leech@planetinnovation.com.au>
This allows enabling lwIP debugging output. For example, to enable PPP
debugging add the following to `mpconfigboard.h`:
#define LWIP_DEBUG 1
#define PPP_DEBUG LWIP_DBG_ON
Signed-off-by: Damien George <damien@micropython.org>
When timeout=0 (non-blocking mode) the UART should still wait for each
character to go out. Otherwise non-blocking mode with CTS enabled is
useless because it can only write one character at a time.
Signed-off-by: Damien George <damien@micropython.org>
Just adding the event symbol. No code change required, and no impact on
code execution time when the event is not selected.
Tested with STM32F4xx, STM32F7xx and STM32H7xx.
Signed-off-by: robert-hh <robert@hammelrath.com>
The original OSPIFLASH settings in the `mpconfigboard.h` contained some
mistakes that prevented the firmware from compiling. These are now
corrected and the firmware can be built with support for OSPI flash.
Note: external storage in OSPI flash is not yet configured on this board.
Signed-off-by: nspsck <teng.jiang94@gmail.com>
Added a #if-block to `system_stm32.c` to check whether
`MICROPY_HW_RCC_OSPI_CLKSOURCE` is defined. If that is the case, the
clock source for the OSPI will be changed to the specified source.
Signed-off-by: nspsck <teng.jiang94@gmail.com>
Added a if-statement to `octospi.c` to detect if the targeted MCU is one of
the STM32H7 series. If that is the case, another set of variables are used
for the `mp_hal_pin_config_alt_static_speed()` function, as well as for
register `OCTOSPI1->CR`. This allows the STM32H723 and STM32H7B3 series
MCU to use octo-spi flash like the STM32H573 series MCU.
Signed-off-by: nspsck <teng.jiang94@gmail.com>
There is a gap in support for the PVD interrupt on STM32WBxx and STM32WLxx.
This has been tested on NUCLEO_WB55 with the example code:
from pyb import Pin, ExtInt
def callback(line):
print(line)
PVD = 16
exti = ExtInt(PVD, ExtInt.IRQ_RISING_FALLING, Pin.PULL_DOWN, callback)
exti.swint()
Before this commit the CPU locks up as soon as the final line is run.
After this commit it prints "16".
Fixes issue #15548.
Signed-off-by: Andrew Leech <andrew.leech@planetinnovation.com.au>
There are some missing images at MicroPython Downloads. This commit
attempts to resolve all the current issues, and add product URLs where
missing.
Signed-off-by: Matt Trentini <matt.trentini@gmail.com>
The reason for this change is that it makes allows custom code, that needs
to use an MPU region, to find a free one by using this macro or starting
from the max number and downwards, without concern that it might change in
the future.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
Swap FMC banks to remap the SDRAM bank1 address to 0x60000000. Arduino's
M4 firmware uses address 0x60000000 by default. When the elf loader tries
to load that it will fail because by default NOR/PSRAM is mapped at that
address, not SDRAM bank1. (Note that the region at 0xC0000000 has an XN
attribute by default, so switching the M4 firmware address will not work.)
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
This simplifies configuration by removing the `MICROPY_PY_OS_SEP` option
and instead including `os.sep` if `MICROPY_VFS` is enabled. That matches
the configuration of all existing ports that enabled `os.sep` (they also
had `MICROPY_VFS` enabled), and brings consistency to other ports.
Fixes issue #15116.
Signed-off-by: Damien George <damien@micropython.org>
The limit is set by a `MICROPY_PY_MACHINE_FREQ_NUM_ARGS_MAX` define, which
defaults to 1 and is set for stm32 to 4.
For stm32 this fixes a regression introduced in commit
e1ec6af654 where the maximum number of
arguments was changed from 4 to 1.
Signed-off-by: robert-hh <robert@hammelrath.com>
Compiling using arm-none-eabi-gcc 14.1.0 with -O2 will give warnings about
possible overflow indexing extint arrays, such as `pyb_extint_callback`.
This is due to `machine_pin_obj_t.pin` having a bit-width of 5, and so a
possible value up to 31, which is usually larger than
`PYB_EXTI_NUM_VECTORS`.
To fix this, change `machine_pin_obj_t.pin` to a bit-width of 4. Only 4
bits are needed for ST MCUs, which have up to 16 pins per port.
Signed-off-by: Damien George <damien@micropython.org>
Fixes automatic baudrate calculation results.
Default clock source on this SoC is HSE not PCLK1. We could fix this by
switching to PCLK1 instead, but two extra complications:
- PCLK1 on this board is a 42.5MHz and the Pyboard CAN sample_point
calculation requires an exact match, which is harder to hit with this
source frequency.
- Would be a breaking change for any existing Python code on this board,
i.e. specifying brp, bs1, bs2 to initialise CAN.
In the future it might be worth looking switching to the PLL source on this
SoC instead, as this is a much higher frequency that would give higher
quality BRS bitrate matches (probably too high without using the second
divider going into the CAN peripheral though, so more code changes needed
also).
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
Different MCUs have different requirements for the minimum number of bytes
that can be written to internal flash.
Signed-off-by: Damien George <damien@micropython.org>
The calculations `num_word32 / 4` and `num_word32 / 8` were rounding down
the number of words to program to flash, and therefore possibly truncating
the data (eg mboot could miss writing the final few words of the firmware).
That's fixed in this commit by adding extra logic to program any remaining
words. And the logic for H5 and H7 is combined.
Signed-off-by: Damien George <damien@micropython.org>
In case there is a power failure after during this operation, the key must
be the last thing that is written, to indicate valid data.
Signed-off-by: Damien George <damien@micropython.org>
The default CYW43 WiFi AP settings were missing the security mode, leaving
the AP in open mode by default. That's changed by this commit to use
WPA/WPA2 by default.
Signed-off-by: iabdalkader <i.abdalkader@gmail.com>
The C-based SPI flash driver is needed because the
`_copy_file_to_raw_filesystem()` function must copy from a filesystem (eg
FAT) to another part of flash, and the same C code must be used for both
reading (from FAT) and writing (to flash).
Signed-off-by: Damien George <damien@micropython.org>
This is enabled by default if MBOOT_FSLOAD is enabled, although a board
can explicitly disable it by `#define MBOOT_VFS_RAW (0)`.
Signed-off-by: Damien George <damien@micropython.org>
Damien George