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>
Check a target exists before accessing properties. Otherwise
usermod_gather_sources would recurse into garbage property names and break.
Signed-off-by: Phil Howard <phil@gadgetoid.com>
A long time ago when there was only the `stm` port, Ctrl-C would trigger a
preemptive NLR jump to break out of running code. Then in commit
124df6f8d0 a more general approach to
asynchronous `KeyboardInterrupt` exceptions was implemented, and `stmhal`
supported both approaches, with the general (soft) interrupt taking
priority.
Then in commit bc1488a05f `pyboard.py` was
updated with a corresponding change to make it issue a double Ctrl-C to
break out of any existing code when entering the raw REPL (two Ctrl-C
characters were sent in order to more reliably trigger the preemptive NLR
jump).
No other port has preemptive NLR jumps and so a double Ctrl-C doesn't
really behave any differently to a single Ctrl-C: with USB CDC the double
Ctrl-C would most likely be in the same USB packet and so processed in the
same low-level USB callback, so it's just setting the keyboard interrupt
flag twice in a row. The VM/runtime then just sees one keyboard interrupt
and acts as though only one Ctrl-C was sent.
This commit changes the double Ctrl-C to a single Ctrl-C in `pyboard.py`
and `mpremote`. That keeps things as simple as they need to be.
Signed-off-by: Damien George <damien@micropython.org>
Commit 69c25ea865 made raising `SystemExit`
do a soft reset (on bare-metal targets). This means that any test which is
skipped by a target (by raising `SystemExit`) will trigger a soft reset on
that target, and then it must execute its startup code, such as `boot.py`.
If the timing is right, this startup code can be unintentionally
interrupted by the test runner when preparing the next test, because the
test runner enters the raw REPL again via a Ctrl-C Ctrl-A ctrl-D sequence
(in `Pyboard.enter_raw_repl()`).
When this happens (`boot.py` is interrupted) the target may not be set up
correctly, and it may (in the case of stm32 boards) flash LEDs and take
extra time, slowing down the test run.
Fix this by explicitly waiting for the target to finish its soft reset when
it skips a test.
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>
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>
In idf v5.2.1 if the port flag is set it's validated even on jobs that
don't access hardware like clean. This causes the job to fail if device
isn't connected.
Signed-off-by: Andrew Leech <andrew@alelec.net>
This adds a -f/--force option to the "cp" command, which forces
unconditional copies, in particular does not check the hash.
Signed-off-by: Damien George <damien@micropython.org>
These tests are specifically for the command-line interface and cover:
- resume/soft-reset/connect/disconnect
- mount
- fs cp,touch,mkdir,cat,sha256sum,rm,rmdir
- eval/exec/run
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Signed-off-by: Damien George <damien@micropython.org>
Makes the filesystem command give standard error messages rather than
just printing the exception from the device.
Makes the distinction between CommandError and TransportError clearer.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Changes in this commit:
- Adds transport API `fs_hashfile` to compute the hash of a file with given
algorithm.
- Adds commands `mpremote <...>sum file` to compute and print hashes of
various algorithms.
- Adds shortcut `mpremote sha256sum file`.
- Uses the hash computation to improve speed of recursive file copy to
avoid copying a file where the target is identical.
For recursive copy, if possible it will use the board's support (e.g.
built-in hashlib or hashlib from micropython-lib), but will fall back to
downloading the file and using the local implementation.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Signed-off-by: Damien George <damien@micropython.org>
This introduces a Python filesystem API on `Transport` that is implemented
entirely with eval/exec provided by the underlying transport subclass.
Updates existing mpremote filesystem commands (and `edit) to use this API.
Also re-implements recursive `cp` to allow arbitrary source / destination.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Signed-off-by: Damien George <damien@micropython.org>
This is a step towards making the transport expose a Python API rather than
functions that mostly print to stdout.
Most use cases of `transport.eval()` are to get some state back from the
device, so have it return as a value directly by default.
Updates uses of `transport.eval()` to remove the parse argument where it
now isn't needed, make the `rtc` command use eval/exec, and update the
`mip` command to use eval's parsing.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
In MSVC debug builds with debug error reporting set to showing a dialog (to
allow attaching the debugger), any application which imports the logging
module and leaves the default handlers would result in this dialog because
logging.shutdown is called at exit and that flushes the default handler
which has stderr as its stream.
This commit fixes that by not fsync'ing stdin/out/err.
Also adds a comment related to checking whether a file is stdin/out/err,
which is difficult to fix properly.
Signed-off-by: stijn <stijn@ignitron.net>
Allowing passing keyword arguments to a native base's __init__, i.e.
`make_new` in the C code. Previously only positional arguments were
allowed.
The main trade-off in this commit is that every call to the native base's
`make_new` is now going to be preceded by a call to
`mp_map_init_fixed_table` even though most of what that does is unused and
instead it merely serves as a way to pass the number of keyword arguments.
Fixes issue #15465.
Signed-off-by: stijn <stijn@ignitron.net>
Enables support for the ESP standard DTR/RTS based reboot to bootloader.
Switches from OTG to Serial/Jtag mode to workaround issue discussed
in: https://github.com/espressif/arduino-esp32/issues/6762
Signed-off-by: Andrew Leech <andrew@alelec.net>
Uses newer TinyUSB synopsys/dwc2 driver for esp32s2 and esp32s3 rather than
the IDF tinyusb component. This allows re-use of other tinyusb integration
code and features shared between ports.
Signed-off-by: Andrew Leech <andrew@alelec.net>
The cyw43-driver uses `printf` by default for `CYW43_PRINTF`, but on the
rp2 port `printf` only goes to a UART output and not to USB CDC.
By defining `CYW43_PRINTF` to `mp_printf`, all the messages from the
cyw43-driver are seen on USB CDC.
For example this allows `network.WLAN().config(trace=1)` to show async
WALN events.
Signed-off-by: Damien George <damien@micropython.org>
The version of the assembly code for the GC helper that was committed
ended up being a version that had an opcode typo in.
The code was tested and working, but an undo operation too many when
cleaning up the file before committing checked in the wrong version.
Signed-off-by: Alessandro Gatti <a.gatti@frob.it>
The `MICROPY_FORCE_PLAT_ALLOC_EXEC` config option was made obsolete by
commit 9796625457, so remove it.
Signed-off-by: Damien George <damien@micropython.org>
Zephyr v3.7.0 added a new feature to allow getting devices by their
devicetree node labels. Use this feature in the MicroPython Zephyr port
to simplify constructing machine module objects, including Pin, SPI,
I2C, and UART. It's still possible to use the more verbose device names
(e.g., gpio@400ff040, i2c@40066000, spi@4002c000), but now we can also
use their devicetree node labels (e.g., gpiob, i2c0, spi0).
Node labels aren't standardized across all SoC families because they
generally try to follow their respective SoC hardware user manual naming
convention, however many boards define common labels for devices routed
to Arduino headers (e.g., arduino_i2c, arduino_serial, and arduino_spi).
That means I2C("arduino_i2c") will work on quite a few boards (>100 in
the main Zephyr tree).
Signed-off-by: Maureen Helm <maureen.helm@analog.com>
