Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: The Natural Philosopher <tnp@invalid.invalid>
Newsgroups: comp.sys.raspberry-pi,sci.electronics.design
Subject: Re: RP2040 reset idea
Date: Sun, 22 Sep 2024 09:37:34 +0100
Organization: A little, after lunch
Lines: 62
Message-ID: <vcol0e$24ol2$7@dont-email.me>
References: <biphejl03r86ebf5dkpcav9ud7u8vcjclj@4ax.com>
 <b+f*To1Uz@news.chiark.greenend.org.uk>
 <jidrej5t93mud6asmgvis4rcetolmqa6ta@4ax.com> <vclv4m$1he37$2@dont-email.me>
 <0be4sk-4bp.ln1@coop.radagast.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 22 Sep 2024 10:37:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b83977870f773d29c3595abc7b614c8d";
	logging-data="2253474"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+xeUmc2KPWUxeGx8gp3V13WrYK2fsnA+k="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:py86q0KajQa2RsRDCBiYk+JT0QM=
Content-Language: en-GB
In-Reply-To: <0be4sk-4bp.ln1@coop.radagast.org>
Bytes: 3676

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.