The micro:bit board (and probably other boards using the music or display
module) locked up on soft reboot. Reason was a buffer overflow caused by
an index counter, which was not reset on soft_reboot.
That's fixed in this commit. Tested with a micro:bit board, performing a
series of soft reboots.
Signed-off-by: robert-hh <robert@hammelrath.com>
Closes#13178.
TouchPad confirmed working on both chips, and fixes the the ESP32-S3
reading constant max value. Was unable to reproduce the bug on ESP32-S2 but
this may be due to my test setup, and it still works with the fix.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
ESP32 has hardware V1 and S2/S3 has V2, and future chips
may have different versions.
This should still compile to the same binary before and after.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
- Previously the call to esp_wifi_set_channel() would be immediately
overridden by calling esp_wifi_config(...) with the previous channel set.
- AP interface doesn't seem to need more than esp_wifi_config(...) to work.
It will automatically configure 40MHz bandwidth and place the secondary
channel using similar logic to what was being explicitly calculated here.
- However, calling esp_wifi_set_channel() on the STA interface is necessary
if using this interface with ESP-NOW (without connecting to an AP). So
the esp_wifi_set_channel() call is kept in for this purpose. Without
this, tests/multi_espnow/70_channel.py fails.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
Because the `ai_canonname` field is subsequently used.
ESP32_GENERIC_S3 (at least) crashes with IDF 5.2.3 without this set.
Signed-off-by: Damien George <damien@micropython.org>
Seemingly ESP-IDF incorrectly marks RTC FAST memory region
as MALLOC_CAP_EXEC on ESP32-S2 when it isn't. This memory is
the lowest priority, so it only is returned if D/IRAM is exhausted.
Apply this workaround to treat the allocation as failed if it gives us
non-executable RAM back, rather than crashing.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
The cleanup in 548babf8 relies on some functions not available in older
ESP-IDF. Temporarily restore them, until we drop support for ESP-IDF <5.2.
PWM functionality should end up the same regardless of ESP-IDF version, and
also no different from MicroPython V1.23.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
The PIC16 port didn't catch up with the other ports, so it required a bit
of work to make it build with the latest version of XC16.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This commit fixes PWM configuration across C3, C6, S2 and S3 chips, which
was broken by 6d799378ba. Without this fix
the PWM frequency is limited to a maximum of 2446Hz (on S2 at least).
Signed-off-by: Andrew Leech <andrew@alelec.net>
Prior to this fix, `tests/extmod/vfs_lfs_mtime.py` would fail when run
after the `tests/ports/rp2/rp2_lightsleep.py` test, because
`time.time_ns()` would have a large and constant offset from `time.time()`.
Fix this by re-syncing the time-ns offset when coming out of lightsleep.
Signed-off-by: Damien George <damien@micropython.org>
The port configuration file tagged callable pointers' LSB on both Arm
and RISC-V variants. This is needed on Arm due to Thumb/Thumb2
code addresses having their LSB set, but on RISC-V this is not required.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
This reverts commit c94a3205b0.
The idea behind this reverted commit was that it allowed to reconfigure the
UART to change only the baudrate, which is important in the context of a
PPP connection where the baudrate may be changed as part of the protocol.
Also, other ports like the rp2 port have this behaviour, where individual
parameters of the UART can be changed with the `.init()` method.
But this commit was no good for a few reasons:
1. It's a subtle breaking change to the UART API, because existing code
that constructs or initialises a UART with just the baudrate would
expect all other parameters to be reset to their defaults. But with
this commit those parameters would remain unchanged.
2. Constructing a UART like `UART(1, 9600)` also hits this code path of
only changing the baudrate and does not reset other parameters, which is
unexpected.
3. It doesn't support setting the baudrate via keyword, eg
`UART.init(baudrate=9600)`.
4. The `timeout_char` field is not updated when changing only the baudrate,
which can lead to unexpected timeouts when reading/writing.
Due to point (4), this commit broke the `tests/ports/stm32/uart.py` test,
the `uart.writechar(1)` has a timeout because the `uart.init(2400)` does
not set the `timeout_char` for the new baudrate.
Points (2)-(4) could be fixed, but point (1) (being a breaking change)
would remain as an issue. So the commit is reverted.
Signed-off-by: Damien George <damien@micropython.org>
Prior to this commit, when flushing a UART on the rp2 port, it returns just
before the last character is sent out the wire.
Fix this by waiting until the BUSY flag is cleared.
This also fixes the behaviour of `UART.txdone()` to return `True` only when
the last byte has gone out.
Updated docs and tests to match. The test now checks that UART TX time is
very close to the expected time (prior, it was just testing that the TX
time was less than the expected time).
Signed-off-by: Damien George <damien@micropython.org>
This fixes a regression introduced in commit
4247921c4e, where this ring-buffer polling
was accidentally put inside the `#if MICROPY_HW_ESP_USB_SERIAL_JTAG`.
Signed-off-by: Andrew Leech <andrew@alelec.net>
NUM_GPIOS amd NUM_EXT_GPIOS are currently hardcoded in make-pins.py, which
makes it difficult to support SoCs with different pin count.
This commit generalises make-pins.py by passing in the pin count in via the
new arguments `--num-gpios` and `--num-ext-gpios`. These default to the
current values supported by Pico, namely 30/10. This can be changed with
PICO_NUM_GPIOS and PICO_NUM_EXT_GPIOS in `mpconfigboard.cmake`.
Signed-off-by: Damien George <damien@micropython.org>
Add support for 32 and 48 pin variants of RP2350.
Add new `PIO.gpio_base()` method, mirroring the Pico SDK.
Signed-off-by: Phil Howard <phil@gadgetoid.com>
Signed-off-by: Damien George <damien@micropython.org>
This commit separates various build settings and include files that are
specific to RP2040 and RP2350, and uses the aon_timer interface instead of
rtc, to work across both MCU variants.
Signed-off-by: Damien George <damien@micropython.org>
Signed-off-by: Phil Howard <phil@gadgetoid.com>
Two new bits were added to the ctrl register, and existing bits were
shifted, so use DMA_CH0_CTRL_TRIG_xxx constants to generalise the code.
Signed-off-by: Damien George <damien@micropython.org>
This isn't fully working, the CPU often wakes up early. That will be fixed
when a newer version of pico-sdk is released.
Signed-off-by: Damien George <damien@micropython.org>
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>
This is a workaround for a bug in ESP-IDF where the configuration setting
for maximum active TCP sockets (PCBs) is not applied.
Fixes cases where a lot of short-lived TCP connections can cause:
- Excessive memory usage (unbounded number of sockets in TIME-WAIT).
- Much higher risk of stalled connections due to repeated port numbers. The
maximum number of active TCP PCBs is reduced from 16 to 12 to further
reduce this risk (trade-off against possibility of TIME-WAIT
Assassination as described in RFC1337).
This is not a watertight fix for the second point: a peer can still reuse a
port number while a previous socket is in TIME-WAIT, and LWIP will reject
that connection (in an RFC compliant way) causing the peer to stall.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
