Added New Port PSOC Edge (II) - #18910

Code size report:

Reference:  tools/mpremote: Fix instructions for running single test. [b50c280]
Comparison: github/workflows/ports_psoc-edge.yml: Add psoc edge build ci check. [merge of e536f45]
  mpy-cross:    +0 +0.000% 
   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
      esp32:    +0 +0.000% ESP32_GENERIC
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.55%. Comparing base (772df1a) to head (e536f45).
⚠️ Report is 14 commits behind head on master.

@@            Coverage Diff             @@
##           master   #18910      +/-   ##
==========================================
+ Coverage   98.51%   98.55%   +0.03%     
==========================================
  Files         179      179              
  Lines       23243    23244       +1     
==========================================
+ Hits        22899    22908       +9     
+ Misses        344      336       -8     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

@jaenrig-ifx thanks for posting this PR, upon first glance it looks really great! I was able to build it without any trouble and deploy it to the E84-AI board. And the REPL appeared. Excellent!

I will look at it in more detail.

If you want something to work on, see if you can get tests/serial_test.py to pass:

$ ./tests/serial_test.py

That should automatically connect to the device (assuming it's the only thing plugged in) and run the test. It currently fails (for me). To get it working, you'll probably need to implement the UART RX IRQ and store incoming characters from the UART into a stdin ringbuf, and make that ringbuf around 260 bytes big. See shared/tinyusb/mp_usbd_cdc.c:tud_cdc_rx_cb() and ports/esp32/uart.c:uart_irq_handler() for hints.

@jaenrig-ifx thanks for posting this PR, upon first glance it looks really great! I was able to build it without any trouble and deploy it to the E84-AI board. And the REPL appeared. Excellent!

I will look at it in more detail.

Perfect, glad to hear 😊

If you want something to work on, see if you can get tests/serial_test.py to pass:

$ ./tests/serial_test.py

That should automatically connect to the device (assuming it's the only thing plugged in) and run the test. It currently fails (for me). To get it working, you'll probably need to implement the UART RX IRQ and store incoming characters from the UART into a stdin ringbuf, and make that ringbuf around 260 bytes big. See shared/tinyusb/mp_usbd_cdc.c:tud_cdc_rx_cb() and ports/esp32/uart.c:uart_irq_handler() for hints.

Ok, let us take care of that soon. 👌 We have some retarget-io (a ModusToolbox uart - printf redirect lib) which we should review anyhow.

@jaenrig-ifx I'm wondering what the next steps are with this PR. Are you working on the serial port improvements? Or are you waiting for a more detailed review from me?

I think the general approach here is good, so I'm happy to go through and make detailed comments to get this ready for merging.

Hi @dpgeorge!

@jaenrig-ifx is on vacation until mid of next week, so I'm jumping in.

We're planning to take the serial port improvements together with enabling the machine.UART module.

For the next steps it would be great to get a more detailed review from your side, so that we can soon work on the improvements and clear the path to get this PR merged.

Thanks!
Julian

Dear @dpgeorge,

Sorry for the inactivity. As @ederjc mentioned I was some weeks off.
Thanks for all the feedback!
We will work on all of it along the upcoming weeks, together with the UART topic :)

@jaenrig-ifx thanks for responding to my review.

From your side, how much is left to do here? Is it just the UART that you are working on, or other things as well?

@jaenrig-ifx thanks for responding to my review.

From your side, how much is left to do here? Is it just the UART that you are working on, or other things as well?

Focus for me and left to do for this PR:

• machine.UART is WIP, and that will be reused for the UART REPL, and ensure the tests/serial_test.py passes.
• mpy-pse.py refactor
• use existing lib/cmsis

In parallel my colleagues are working on these:

• machine.I2C
• machine.SPI
• network.WLAN
• machine.PDM_PCM (port specific) -> Potential generalization of extmod/I2S into extmod/machine_daudio?.
• machine.IPC (port specific) -> Preliminary dual core support, and eventually this allows/supports openamp enablement.

Some of them have a good coverage of features already, and available in our main. But we will open subsequent PRs for each of them once this PR is handled😊

After that, we plan further coverage of the machine.xxx features.

If you think that is convenient to prioritize the enablement of other certain features before, maybe that can be aligned with @ederjc.

Focus for me and left to do for this PR:

If we can tick off these 3 items of yours (UART, mpy-pse.py, cmsis) then I think this PR will be very close to merge.

• machine.UART is WIP, and that will be reused for the UART REPL, and ensure the tests/serial_test.py passes.
• mpy-pse.py refactor

Hi @dpgeorge ,

The latest commits should complete these 2 issues. I tried not to add more files than necessary, but some alternate functions enablement extra sources has been also added or extended to support the machine.UART based REPL enablement.
The test/serial_test.py looks like passing now:

We look forward to your feedback 😊.
Thanks!

Thanks @jaenrig-ifx for updating. It's looking really very good now! I managed to build the firmware straightaway without any issues (just needed pip install edgeprotecttools), and could download it to the board using Infineon's OpenOCD.

I see that it has a filesystem using external QSPI which is great. And I was able to run the test suite.

Some initial feedback:

• probably need to enable MICROPY_PY_MATH_GAMMA_FIX_NEGINF to fix math.gamma(-inf) (see the test tests/float/math_domain_special.py which should pass)
• time.time() does not match time.time_ns() * 1e-9; is there any way to fix this?
• is it possible to construct a UART other than UART(0)? to match the standard API, machine.UART(id, ...) should take an (optional) id as the first argument to select the UART instance, even if there's only one possible UART that can be used (the id can be optional and default to instance 0, but it should still be possible to pass in an id)
• boards/manifest.py is never used. I suggest removing the board-specific manifest.py and instead just default to using the common boards/manifest.py
• I downloaded the latest OpenOCD version 5.16.1 and it works on my Arch Linux machine. Can we recommend that version as the one to use? Or did you deliberately list the minimum required version?

Thanks @jaenrig-ifx for updating. It's looking really very good now! I managed to build the firmware straightaway without any issues (just needed pip install edgeprotecttools), and could download it to the board using Infineon's OpenOCD.

I see that it has a filesystem using external QSPI which is great. And I was able to run the test suite.

Thanks @dpgeorge for following up this PR! Great 👍 Glad to hear!

Some initial feedback:

• probably need to enable MICROPY_PY_MATH_GAMMA_FIX_NEGINF to fix math.gamma(-inf) (see the test tests/float/math_domain_special.py which should pass)

Done!

• time.time() does not match time.time_ns() * 1e-9; is there any way to fix this?

Yes. This does not make much sense:

=== time.time_ns()
=== time.time()
17314352790592971616
89926744968036

Based on the code comments, it seems some time functions might require some review. I'll work on it.

• is it possible to construct a UART other than UART(0)? to match the standard API, machine.UART(id, ...) should take an (optional) id as the first argument to select the UART instance, even if there's only one possible UART that can be used (the id can be optional and default to instance 0, but it should still be possible to pass in an id)

I added the option to pass an id but it is ignored by our port. Is that okay? At least for now?

We could add this id <-> port-pins mapping. The id can be mapped to the Serial Communication Block (SCB) index.
This would ease the instantiation if the pins are automatically resolved and don't need to be passed in the constructor.

But to avoid the need of going through the MCU manual and lengthy docs to find the ids, we should provide as well a pinout diagram with the matching pin.board.<label> with label = <protocol><scb>_<signal). For example: UART0_TX, for SCB0.

Still, one needs to physically connect those pins and locate them on the board. In that case, not sure if all this id mapping
pays-off (?).

• boards/manifest.py is never used. I suggest removing the board-specific manifest.py and instead just default to using the common boards/manifest.py

Done!

• I downloaded the latest OpenOCD version 5.16.1 and it works on my Arch Linux machine. Can we recommend that version as the one to use? Or did you deliberately list the minimum required version?

Yes, the latest version also works. The minimum OpenOCD version is still v5.8.0, as this is the first supporting the PSOC Edge.
I updated the ports/psoc-edge/README.md. I removed the reference to the MTB programming tools, and now I only point to the Infineon OpenOCD repo.

@jaenrig-ifx thanks for updating based on feedback.

My aim is to try and get all the existing tests passing on the KIT_PSE84_AI board (all the tests that can run on it, that don't automatically skip). We are getting there!

Let's try to get the UART tests passing. Or at the very least running without locking the board up. Those tests are tests/extmod/machine_uart*.py and tests/extmod_hardware/machine_uart*.py.

Starting with the basic tests/extmod/machine_uart_tx.py test, the first thing to do is create a target_wiring.py file and copy it to the board. Here's what I'm trying:

# Target wiring for KIT_PSE84_AI.

# UART(5) is on P17_1/P17_0.
uart_loopback_args = ()
uart_loopback_kwargs = {"tx": "P17_1", "rx": "P17_0"}

Then do mpremote run tests/extmod/machine_uart_tx.py. That doesn't work very well and locks up most of the time.

Investigating, even constructing the UART is problematic:

MicroPython v1.29.0-preview.291.g8ce0af4fcb on 2026-05-19; KIT_PSE84_AI with PSOCE84
Type "help()" for more information.
>>> import machine
>>> machine.UART(tx="P17_1", rx="P17_0")
UART(tx='P17_1',
rx='P17_0',
baudrate=115200,
bits=8,
parity=0,
stop=2,
flow=0,
timeout=0,
timeout_char=1,
rxbuf=256)
>>> machine.UART(tx_"P17_1", rx="P17_0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: SCB 5 is already in use by another I2C, SPI or UART instance.
>>>

So it's not possible to construct the UART a second time. On other ports this is possible, and probably to achieve that you need to pass in the SCB id (UART id) that you want to use, which in the case above is UART(5).

From looking at the af tables, it seems that it's quite restrictive what UART is connected to what pins. That's similar to stm32, so we can handle it in a similar way:

• the board config defines the default pins for each available UART instance (or at least for a few UART instances) and usually these UARTs and pins are the ones easily available on the headers on the board
• then the user can easily do eg machine.UART(5) and construct the default UART5 with the default board pins
• doing machine.UART(5) again will retrieve the existing object, and reinit it if extra args are passed to the constructor
• you can explicitly select tx/rx pins if needed using machine.UART(5, tx=..., rx=...)

Because the PSE84 has restrictions for the UART and pin mappings, the user really needs to know this in order to use the peripheral.

You could also keep the existing functionality in this PR and let the SCB/UART id be auto selected based on the pins. But it should also be possible to manually select the UART id so you can reuse a UART if needed (without first doing .deinit()). This behaviour will match other ports.

I was also trying to create a UART on other pins (the ones connected to the header on the board) so I could connect it up in loopback mode, but that also failed. Eg:

MicroPython v1.29.0-preview.291.g8ce0af4fcb on 2026-05-19; KIT_PSE84_AI with PSOCE84
Type "help()" for more information.
>>> import machine
>>> machine.UART(tx="P16_1", rx="P16_0")
(locks up here)

and

MicroPython v1.29.0-preview.291.g8ce0af4fcb on 2026-05-19; KIT_PSE84_AI with PSOCE84
Type "help()" for more information.
>>> import machine
>>> machine.UART(tx="P17_3", rx="P17_2")
(locks up here)

I understand one of the UARTs is used for the REPL, but surely that's not the reason the above is locking up?

A few other minor issues I noticed:

• please start all Python exception messages with a lowercase letter (there are at least 2 in machine_uart.c that need changing)
• in mp_machine_uart_print() don't print any newlines
• Pin.irq(None) should disable the pin IRQ

Hi @dpgeorge,

My aim is to try and get all the existing tests passing on the KIT_PSE84_AI board (all the tests that can run on it, that don't automatically skip). We are getting there!

Thanks for taking the time and effort here 😊
Any group of tests we can prioritize, and start testing on our own?

Currently, we are just adding to our CI HIL basic functional tests (sunny side mostly) mainly our port enablement (machine, network.WLAN,...)
They at least ensure that we can "talk" to the device via REPL, VFS works, and our port enablement is not deviating from the upstream.

At a later stage, this should be iterated and reusable from extmod_hardware tests. Maybe also generalize and extend those tests to be run by all ports. But let´s not grow the scope of this PR 😅

For the rest of the tests, we are assume what comes from the upstream "works". I am aware that is a bit naive and that our CI coverage is low. It is just a matter or prioritization and capacity.

Let's try to get the UART tests passing. Or at the very least running without locking the board up. Those tests are tests/extmod/machine_uart*.py and tests/extmod_hardware/machine_uart*.py.

Starting with the basic tests/extmod/machine_uart_tx.py test, the first thing to do is create a target_wiring.py file and copy it to the board. Here's what I'm trying:

# Target wiring for KIT_PSE84_AI.

# UART(5) is on P17_1/P17_0.
uart_loopback_args = ()
uart_loopback_kwargs = {"tx": "P17_1", "rx": "P17_0"}

Then do mpremote run tests/extmod/machine_uart_tx.py. That doesn't work very well and locks up most of the time.

Let me run it, and make sure it works 😊

Investigating, even constructing the UART is problematic:

MicroPython v1.29.0-preview.291.g8ce0af4fcb on 2026-05-19; KIT_PSE84_AI with PSOCE84
Type "help()" for more information.
>>> import machine
>>> machine.UART(tx="P17_1", rx="P17_0")
UART(tx='P17_1',
rx='P17_0',
baudrate=115200,
bits=8,
parity=0,
stop=2,
flow=0,
timeout=0,
timeout_char=1,
rxbuf=256)
>>> machine.UART(tx_"P17_1", rx="P17_0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: SCB 5 is already in use by another I2C, SPI or UART instance.
>>>

So it's not possible to construct the UART a second time. On other ports this is possible, and probably to achieve that you need to pass in the SCB id (UART id) that you want to use, which in the case above is UART(5).

From looking at the af tables, it seems that it's quite restrictive what UART is connected to what pins. That's similar to stm32, so we can handle it in a similar way:

• the board config defines the default pins for each available UART instance (or at least for a few UART instances) and usually these UARTs and pins are the ones easily available on the headers on the board
• then the user can easily do eg machine.UART(5) and construct the default UART5 with the default board pins
• doing machine.UART(5) again will retrieve the existing object, and reinit it if extra args are passed to the constructor
• you can explicitly select tx/rx pins if needed using machine.UART(5, tx=..., rx=...)

Because the PSE84 has restrictions for the UART and pin mappings, the user really needs to know this in order to use the peripheral.

You could also keep the existing functionality in this PR and let the SCB/UART id be auto selected based on the pins. But it should also be possible to manually select the UART id so you can reuse a UART if needed (without first doing .deinit()). This behaviour will match other ports.

The current approach was more, you would call init() over the returned object to reconfigure:
uart = machine.UART(...) -> uart.init(...).
Let me try to rework to comply with all these specs.
Then I need to also make sure that if another machine class is using that SCB block it can be deinitialized. For example, if we have an I2C instance over those same pins, and we call machine.UART(xxx) this will deallocate/deinit that object and reconfigure those pins and and SCB block for UART.

I was also trying to create a UART on other pins (the ones connected to the header on the board) so I could connect it up in loopback mode, but that also failed. Eg:

MicroPython v1.29.0-preview.291.g8ce0af4fcb on 2026-05-19; KIT_PSE84_AI with PSOCE84
Type "help()" for more information.
>>> import machine
>>> machine.UART(tx="P16_1", rx="P16_0")
(locks up here)

and

MicroPython v1.29.0-preview.291.g8ce0af4fcb on 2026-05-19; KIT_PSE84_AI with PSOCE84
Type "help()" for more information.
>>> import machine
>>> machine.UART(tx="P17_3", rx="P17_2")
(locks up here)

I understand one of the UARTs is used for the REPL, but surely that's not the reason the above is locking up?

I suspect (on bsp-cfg side) probably these pins are already allocated to other peripherals, and they can't be just reallocated and initialized to another peripheral without a previous deinitialization. Another topic to check 👍

A recap of the TODOs:

• use existing lib/cmsis
• time.time() == (time.time_ns() * 1e-9
• machine.UART:
  • start exception messages with a lowercase letter (there are at least 2 in machine_uart.c that need changing)
  • mp_machine_uart_print() don't print any newlines
  • machine.UART() on same instance/pins should allow reinit() withtout calling deinit()
  • Ensure tests/extmod[_hardware]/*uart* test pass
  • Evaluate/fix why machine.UART() hangs on pins which are (in principle) UART capable.
• Pin.irq(None) should disable the pin IRQ

Any group of tests we can prioritize, and start testing on our own?

Here's my test run (run from tests directory, replace a0 with the serial device of the board):

./serial_test.py -t a0 : passes!

./run-tests.py -t a0 : a few failures:

• extmod/time_res.py crashes the device (may need to run it a few times to see the crash)
• extmod/time_time_ns.py fails due to time.time() vs time.time_ns() discrepancy
• extmod/machine_uart_irq_txidle.py fails due to no target-wiring
• extmod/machine_uart_tx.py fails due to no target wiring
• extmod/vfs_lfs_mtime.py fails due to the same time.time_ns() discrepancy

./run-tests.py -t a0 --via-mpy : failures as above, plus:

• micropython/import_mpy_native_gc.py fails due to stack overflow; I suggest making the C stack a little larger (eg by 1k) to get this test to pass

./run-tests.py -t a0 --via-mpy --emit native : failures as above, plus:

• micropython/schedule_sleep.py crashes the device; to fix this mp_hal_delay_ms() must run the event scheduler even if the delay is 0, see 7f7adad for how to get that working

./run-tests.py -t a0 -d extmod_hardware : most skip, but the two that run fail:

• extmod_hardware/machine_uart_irq_break.py fails due to no target wiring
• extmod_hardware/machine_uart_irq_rxidle.py fails due to no target wiring

Once the target wiring is added (might be a good idea to add it in this PR, as the file tests/target_wiring/KIT_PSE84_AI.py) you will see the UART tests failing.

I don't want the scope of this PR to grow too much, but getting the above tests passing will give this new port a solid foundation. And since the machine.UART class is there, we need to make sure it works as expected (and the tests are very good at defining the exact behaviour).

Understood 👍
Let´s try to get those passing step by step. Hopefully we make it to the v1.29.0 release ☺️

@jaenrig-ifx CMSIS_6 is now available in master.

Thanks for updating!

Two minor issues:

• the lib/psoc-edge/cmsis submodule is no longer needed, but partially included here (and somehow messing up the submodules); please remove it from the "lib/psoc-edge: Add psoc-edge submodules libs." commit
• commit "gitmodules: Add psoc-edge port libs." adds the lib/psoc-edge/retarget-io submodule which is not used (and later reverted), so please remove it from that commit

Thanks for updating!

Two minor issues:

• the lib/psoc-edge/cmsis submodule is no longer needed, but partially included here (and somehow messing up the submodules); please remove it from the "lib/psoc-edge: Add psoc-edge submodules libs." commit
• commit "gitmodules: Add psoc-edge port libs." adds the lib/psoc-edge/retarget-io submodule which is not used (and later reverted), so please remove it from that commit

Ups! I missed those.
Hopefully, all fixed now 👍

Thanks! 😊

I maintain mpbuild which tries to simplify building MicroPython boards; I thought you might be interested to know that I've added support for the psoc-edge. So, after installing mpbuild v1.2.0 (uv tool install mpbuild) and docker you can now build any boards in the ports/psoc-edge/boards folder:

$mpbuild build KIT_PSE84_AI

The build container repository is build-micropython-psoc-edge-docker and the container is published to the MicroPython docker hub.

I maintain mpbuild which tries to simplify building MicroPython boards; I thought you might be interested to know that I've added support for the psoc-edge. So, after installing mpbuild v1.2.0 (uv tool install mpbuild) and docker you can now build any boards in the ports/psoc-edge/boards folder:

$mpbuild build KIT_PSE84_AI

The build container repository is build-micropython-psoc-edge-docker and the container is published to the MicroPython docker hub.

Thanks a lot @mattytrentini !
This is indeed very helpful 😊.

Merged!!

Thanks @jaenrig-ifx and everyone else who contributed to this new port. It took a while but the effort was worth it, and it's now in an excellent state.

Merged!!

Thanks @jaenrig-ifx and everyone else who contributed to this new port. It took a while but the effort was worth it, and it's now in an excellent state.

Wonderful! 😊 The whole team here is very happy about this achievement.
Thanks a lot for also for your endless patience and work you put into this topic🙏!