Subj : Re: RP2040 reset idea
To   : Dave Platt
From : The Natural Philosopher
Date : Sun Sep 22 2024 09:37:34

XPost: sci.electronics.design

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.

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

.