You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a small module that can be linked into an application to allow a quick double-reset to restart into UF2 loader mode. On the RP2040 this works as long as you simply include target_link_libraries(... pico_bootsel_via_double_reset ...) as it runs as part of the C++ constructor sequence.
Unfortunately, while this compiles and runs on the RP2350 (-DPICO_PLATFORM=rp2350) it doesn't function properly.
I've increased the wait time via the define, but it's not related to this (i.e. it's not being reset too quick or slow).
When I did some snooping, it seems like main SRAM and the two 4K stack SRAMs are a) 0-filled after a UF2 upload, but b) pseudo-random filled after a HW (!RUN ) reset on the Pico2-ARM mode.
Maybe this is part of the secure booting process? If so, is there some RAM that's not wiped and not used during start up that we can stuff those magic values in?
Steps to reproduce
In pico-examples, update the basic blink_simple CMakefile.txt
earle@amd:~/src/pico-examples/blink_simple$ git diff .
diff --git a/blink_simple/CMakeLists.txt b/blink_simple/CMakeLists.txt
index 0d7c0cb..32e897b 100644
--- a/blink_simple/CMakeLists.txt
+++ b/blink_simple/CMakeLists.txt
@@ -3,7 +3,7 @@ add_executable(blink_simple
)
# pull in common dependencies
-target_link_libraries(blink_simple pico_stdlib)
+target_link_libraries(blink_simple pico_stdlib pico_bootsel_via_double_reset)
# create map/bin/hex/uf2 file etc.
pico_add_extra_outputs(blink_simple)
And build with -DPICO_PLATFORM=rp2350. Building the same for RP2040 works perfectly.
The text was updated successfully, but these errors were encountered:
Ah, RP2350 has this support in the bootrom, but you have to enable it via:
// -----------------------------------------------------------------------------
// Field : OTP_DATA_BOOT_FLAGS1_DOUBLE_TAP
// Description : Enable entering BOOTSEL mode via double-tap of the RUN/RSTn
// pin. Adds a significant delay to boot time, as configured by
// DOUBLE_TAP_DELAY.
//
// This functions by waiting at startup (i.e. following a reset)
// to see if a second reset is applied soon afterward. The second
// reset is detected by the bootrom with help of the
// POWMAN_CHIP_RESET_DOUBLE_TAP flag, which is not reset by the
// external reset pin, and the bootrom enters BOOTSEL mode
// (NSBOOT) to await further instruction over USB or UART.
As you suspected, RAM is zeroed in the boot path.
We likely forgoot about ramifications on this library. We should either make clear this library functionality is disabled on RP2350; or implement it differently for RP2350 (if having non OTP chosen way is useful which it might be). Thoughts @Wren6991
Overview
There is a small module that can be linked into an application to allow a quick double-reset to restart into UF2 loader mode. On the RP2040 this works as long as you simply include
target_link_libraries(... pico_bootsel_via_double_reset ...)
as it runs as part of the C++ constructor sequence.Unfortunately, while this compiles and runs on the RP2350 (
-DPICO_PLATFORM=rp2350
) it doesn't function properly.Debugging
On inspection, it seems like the magic numbers that are written to SRAM are actually overwritten by the Pico2 bootrom processing (with what looks to me to be repeatable, pseudo-random data) so that it can never actually match by the time the main app starts up and calls the C++
(constructor)
that handles this.I've increased the wait time via the define, but it's not related to this (i.e. it's not being reset too quick or slow).
When I did some snooping, it seems like main SRAM and the two 4K stack SRAMs are a) 0-filled after a UF2 upload, but b) pseudo-random filled after a HW (!RUN ) reset on the Pico2-ARM mode.
Maybe this is part of the secure booting process? If so, is there some RAM that's not wiped and not used during start up that we can stuff those magic values in?
Steps to reproduce
In
pico-examples
, update the basicblink_simple
CMakefile.txtAnd build with
-DPICO_PLATFORM=rp2350
. Building the same for RP2040 works perfectly.The text was updated successfully, but these errors were encountered: