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 6d799378bad4474e77ddb2fa2187ecd6e290e0ba. 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 c94a3205b044fb27fa703d5c280fb02a094f12e3.
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
4247921c4ebfced79aa7ccfbb835c9f60ad6f0fc, 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>
Provide stub implementations of localtime_r() and mktime() to avoid
code size increase.
Reported upstream at https://github.com/raspberrypi/pico-sdk/issues/1810
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
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 01156d510c728408be4fd3100bcee18e8985ac00.
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 69c25ea8653566ec97690b5121bd10b753c89426. 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>
Regression introduced in 337742f.
The hang occurs because the esp32 port was calling "from ISR" port-layer
functions to set/clear the interrupt mask. FreeRTOS kernel therefore
doesn't know the CPU is in a critical section. In taskYIELD() the riscv
port layer blocks after yielding until it knows the yield has happened, and
would block indefinitely if IRQs are disabled (until INT WDT triggers).
Moving to the "public" portENTER_CRITICAL/portEXIT_CRITICAL API means that
FreeRTOS knows we're in a critical section and can react accordingly.
Adds a regression test for this case (should be safe to run on all ports).
On single core CPUs, this should result in almost exactly the same
behaviour apart from fixing this case.
On dual core CPUs, we now have cross-CPU mutual exclusion for atomic
sections. This also shouldn't change anything, mostly because all the code
which enters an atomic section runs on the same CPU. If it does change
something, it will be to fix a thread safety bug.
There is some risk that this change triggers a FreeRTOS crash where there
is a call to a blocking FreeRTOS API with interrupts disabled. Previously
this code might have worked, but was probably thread unsafe and would have
hung in some circumstances.
This work was funded through GitHub Sponsors.
Signed-off-by: Angus Gratton <angus@redyak.com.au>
