Fixed the issue that occurred when using the latest pico-sdk(2.2.0) in micropython

[Bohrium332]

Header file path issue

Problem phenomenon

fatal error: pico/platform/common.h: No such file or directory

The fundamental reason: PICO-SDK 2.2.0 reorganized the file structure. The pico/platform/common.h file is from:

src/rp2040/pico_platform/include/pico/platform/common.h

src/rp2350/pico_platform/include/pico/platform/common.h

Moved to a unified location

src/rp2_common/pico_platform_common/include/pico/platform/common.h

However, the #include "pico/platform/common.h" path in the platform.h file has not been updated accordingly.

Solution:

Create symbolic links to link the missing header files to a new location

Result: The pico-sdk version 2.2.0 was successfully used in micropython

[peterharperuk]

I don't think we use sym links to fix issues like this. Micropython needs to add pico_platform_common to PICO_SDK_COMPONENTS.

[Anton-2]

Indeed, this modification in micropython

diff --git a/ports/rp2/CMakeLists.txt b/ports/rp2/CMakeLists.txt
index 81fb76612..ca8d9a028 100644
--- a/ports/rp2/CMakeLists.txt
+++ b/ports/rp2/CMakeLists.txt
@@ -237,6 +237,7 @@ set(PICO_SDK_COMPONENTS
     pico_flash
     pico_multicore
     pico_platform
+    pico_platform_common
     pico_platform_compiler
     pico_platform_panic
     pico_platform_sections

is enough to fix this error.

But then there is a problem of incompatibility with the linker script :

[97%] Linking CXX executable firmware.elf
arm-none-eabi/bin/ld: firmware.elf section `.stack_dummy' will not fit in region `SCRATCH_Y'
arm-none-eabi/bin/ld: region `SCRATCH_Y' overflowed by 4096 bytes

removing the KEEP() around *(.stack*) in ports/rp2/memmap_mp_rp2350.ld allow to link in gives a working firmware, but it's probably not the right thing to do.

Anyway, it looks like something to fix micropython side, and not in pico-sdk.

[peterharperuk]

Here's the fix for the linker script. Maybe I should push a PR (for reference) to fix Micropython for the latest SDK as there are a few issues.

MP uses an 8K stack for core 0 and allocates the stack for core 1 from the heap.

diff --git a/ports/rp2/memmap_mp_rp2040.ld b/ports/rp2/memmap_mp_rp2040.ld
index 5c8d9f471..5fb814399 100644
--- a/ports/rp2/memmap_mp_rp2040.ld
+++ b/ports/rp2/memmap_mp_rp2040.ld
@@ -25,8 +25,8 @@ MEMORY
 {
     FLASH(rx) : ORIGIN = 0x10000000, LENGTH = __micropy_flash_size__
     RAM(rwx) : ORIGIN =  0x20000000, LENGTH = 256k
-    SCRATCH_X(rwx) : ORIGIN = 0x20040000, LENGTH = 4k
-    SCRATCH_Y(rwx) : ORIGIN = 0x20041000, LENGTH = 4k
+    SCRATCH_X(rwx) : ORIGIN = 0x20040000, LENGTH = 0k
+    SCRATCH_Y(rwx) : ORIGIN = 0x20040000, LENGTH = 8k
 }

 ENTRY(_entry_point)
diff --git a/ports/rp2/memmap_mp_rp2350.ld b/ports/rp2/memmap_mp_rp2350.ld
index 1c4770efe..5eb85f53d 100644
--- a/ports/rp2/memmap_mp_rp2350.ld
+++ b/ports/rp2/memmap_mp_rp2350.ld
@@ -25,8 +25,8 @@ MEMORY
 {
     FLASH(rx) : ORIGIN = 0x10000000, LENGTH = __micropy_flash_size__
     RAM(rwx) : ORIGIN =  0x20000000, LENGTH = 512k
-    SCRATCH_X(rwx) : ORIGIN = 0x20080000, LENGTH = 4k
-    SCRATCH_Y(rwx) : ORIGIN = 0x20081000, LENGTH = 4k
+    SCRATCH_X(rwx) : ORIGIN = 0x20080000, LENGTH = 0k
+    SCRATCH_Y(rwx) : ORIGIN = 0x20080000, LENGTH = 8k
 }

[Bohrium332]

Hi @peterharperuk @Anton-2 ,

Thank you very much for your prompt reply and detailed explanation! I fully understand: My symbolic link is just a temporary workaround. The truly elegant fix should be done on the MicroPython side.

I pulled the latest pico-sdk (2.2.0) locally as a MicroPython submodule and retested it. The compilation was successful. The process is as follows (for reference) :

1. Add 'pico_platform_common' to 'PICO_SDK_COMPONENTS' in 'ports/rp2/CMakeLists.txt';

2. My test board is Seeed Studio XIAO RP2350 (RP2350A, single-core version, only 4KB Scratch Y), and the default 8KB stack will overflow. So I Seeed the official board configuration (mpy_cross/variants/SEEED_XIAO_RP2350 / mpconfigboard cmake) manually add a line:

set(PICO_STACK_SIZE 0x1000)  # 4KB

In this way, the SCRATCH_Y overflow will no longer be reported during the linking stage, and the generated firmware will also run perfectly on the board.

The overall experience was excellent. Thank you for analyzing the issues with the path and link script so clearly!

I'm really looking forward to the PR you mentioned being submitted to the MicroPython main repository as soon as possible. In this way, all RP2350 users (including single-core boards like XIAO RP2350) can use it out of the box. If you need my help with testing or providing more logs, feel free to call me at any time!

Thanks again!

[lurch]

(including single-core boards like XIAO RP2350)

I don't know why you think the XIAO RP2350 is a "single-core board" - all RP2350 chips are dual-core 🙂 (Of course not all software is written to use both cores; but that's a software-thing rather than a hardware-thing.)

[Bohrium332]

Thank you for your reminder. This is my oversight. The 2350 is of course dual-core. I apologize again.

[Bohrium332]

I have submitted a pull request to MicroPython, proposing the adoption of version 2.2.0 of the Pico SDK. The link to my pull request is as follows: micropython/micropython#18444. Should any issues be identified, I would greatly appreciate feedback and corrections.

Any assistance would be appreciated.