INTL 3:770/1 3:770/3   
   REPLYADDR dplatt@coop.radagast.org   
   REPLYTO 3:770/3.0 UUCP   
   MSGID: <0be4sk-4bp.ln1@coop.radagast.org> 1cc4f265   
   REPLY:  970c8166   
   PID: SoupGate-Win32 v1.05   
   XPost: sci.electronics.design   
      
   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.   
      
   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)   
   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