INTL 3:770/1 3:770/3   
   REPLYADDR tnp@invalid.invalid   
   REPLYTO 3:770/3.0 UUCP   
   MSGID:  4de5563b   
   REPLY: <0be4sk-4bp.ln1@coop.radagast.org> 1cc4f265   
   PID: SoupGate-Win32 v1.05   
   XPost: sci.electronics.design   
      
   On 22/09/2024 04:08, Dave Platt wrote:   
   > In article ,   
   > The Natural Philosopher   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)   
   SEEN-BY: 10/0 1 90/1 103/705 105/81 106/201 124/5016 129/305 153/757   
   SEEN-BY: 153/7715 218/0 1 601 700 840 870 930 220/70 221/1 6 360 226/17   
   SEEN-BY: 226/30 100 227/114 229/110 111 114 200 206 300 317 400 426   
   SEEN-BY: 229/428 470 550 616 664 700 240/1120 266/512 267/800 282/1038   
   SEEN-BY: 291/111 292/854 301/1 113 812 310/31 320/219 322/757 335/364   
   SEEN-BY: 341/66 342/200 396/45 460/58 633/280 712/848 770/1 3 100   
   SEEN-BY: 770/330 340 772/210 220 230 5020/400 1042 5058/104 5075/35   
   PATH: 770/3 1 218/840 221/6 301/1 218/700 229/426