Re: RP2040 reset idea

On 22/09/2024 04:08, Dave Platt wrote:

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.

That I didnt know.
And is very useful information.

 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.
 

Not had any issues simply drag and dropping to an auto mounted image
UF2 images are over 600k.
--
Climate Change: Socialism wearing a lab coat.