Subj : Re: RP2040 reset idea
To   : tnp@invalid.invalid
From : Dave Platt
Date : Sat Sep 21 2024 20:08:48

XPost: sci.electronics.design

In article <vclv4m$1he37$2@dont-email.me>,
The Natural Philosopher  <tnp@invalid.invalid> wrote:
>It gets nastier if you want to preserve config info across reboots.
>It is possible to read and write areas of flash from the code, but its
>no picnic.

True.  From what I read in the SDK, it appears that the second core
has to be halted temporarily (pushed into a loop running only in SRAM),
and the core doing the erase/flash also has to be running out of SRAM.
Neither can be doing XIP during the flashing, as things will go FOOM
if they are.

>And it gets wiped when new code is uploaded

That may be true of the drag-and-drop-a-UF2-file method.

It's not necessarily true if you use the "picotool" app to
speak directly to the ROM bootloader code.

A little RP2040 (RPi Pico) app I've been working on, uses the
last 32k or so of flash as a bank of "saved parameter" regions,
with version/revision numbers.  My app fits down in the bottom
200k of flash, so there's no collision between the two.

I've reflashed the proto with new versions of the app dozens
of times, and the saved-parameter data has survived each
time.  Apparently, picotool and the bootloader are smart enough
to do a selective erase of only the amount of area needed for
the new version of the app code.

Oh... possible hint for Linux users.  If you're planning to use
the bootloader mass-storage "copy a UF2 image to the device to
re-flash it", you may need to take steps to ensure that the
blocks in the image are actually written to the device in the
same order they're present in the image file.  This isn't
necessarily guaranteed to Linux due to the presence of the
general-purpose block cache and I/O scheduler... the file
blocks might be "pushed" over USB in an arbitrary order.
I've had inconsistent results just doing the simple "mount,
drag-and-drop" process using the desktop file manager.

Possible workaround 1: manually mount the device on a filesystem,
using the "-o sync" option, then drag-and-drop.

Possible workaround 2: mount, then
   dd if=foo.uf2 of=/mnt/foo.uf2 oconv=direct
to bypass the cache.

--- SoupGate-Win32 v1.05
 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

.