Subj : Re: RP2040 reset idea To : tnp@invalid.invalid From : john larkin Date : Sun Sep 22 2024 08:28:22 XPost: sci.electronics.design On Sun, 22 Sep 2024 09:33:48 +0100, The Natural Philosopher wrote: >On 22/09/2024 00:11, john larkin wrote: >> On Sat, 21 Sep 2024 20:46:52 -0000 (UTC), Phil Hobbs >> wrote: >> >>> john larkin wrote: >>>> On Sat, 21 Sep 2024 19:50:34 -0000 (UTC), Phil Hobbs >>>> wrote: >>>> >>>>> john larkin wrote: >>>>>> On Sat, 21 Sep 2024 19:29:26 +0100, The Natural Philosopher >>>>>> wrote: >>>>>> >>>>>>> On 21/09/2024 16:08, john larkin wrote: >>>>>>>> On Sat, 21 Sep 2024 09:12:06 +0100, The Natural Philosopher >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 20/09/2024 19:00, john larkin wrote: >>>>>>>>>> On 20 Sep 2024 11:30:13 +0100 (BST), Theo >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> In comp.sys.raspberry-pi The Natural Philosopher wrote: >>>>>>>>>>>> On 19/09/2024 23:09, Lasse Langwadt wrote: >>>>>>>>>>>>> On 9/18/24 00:33, john larkin wrote: >>>>>>>>>>>> >>>>>>>>>>>>>> It looks like a USB memory stick. You can delete or add files if you >>>>>>>>>>>>>> want. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It boots CPU 0 (the one we call Alice) from a file with the extension >>>>>>>>>>>>>> .UL2 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why   .UL2   one wonders. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We'll put a bunch of files into the flash. Code for Bob, the 2nd CPU. >>>>>>>>>>>>>> An FPGA bitstream file. A prototype calibration table. A README file >>>>>>>>>>>>>> to explain everything in plain English. >>>>>>>>>>>>> >>>>>>>>>>>>> sure it's not UF2? >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/microsoft/uf2 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Definitely uf2 here. >>>>>>>>>>>> >>>>>>>>>>>> And no, you cannot 'delete or add files' to it. >>>>>>>>>>>> The action of pretending to download a uf2 file into what appears to be >>>>>>>>>>>> an empty drive, erases everything on it and programs the flash. >>>>>>>>>>>> >>>>>>>>>>>> There are no visible files to delete. >>>>>>>>>>> >>>>>>>>>>> Neat. So basically you throw some files at it, which causes a series of >>>>>>>>>>> block writes. UF2 picks out specially tagged block writes and uses that to >>>>>>>>>>> program the flash. It doesn't actually care what other stuff is written to >>>>>>>>>>> the flash as it ignores all of that, so it doesn't care about all the FAT >>>>>>>>>>> stuff or whatever junk your OS decides to put on there. >>>>>>>>>>> >>>>>>>>>>> Means you can write any kind of files to it and it'll only pay attention to >>>>>>>>>>> the specific tagged blocks. If the OS is happy to cache the medium (as many >>>>>>>>>>> do) you could maybe even reformat it as some other filesystem like NTFS and >>>>>>>>>>> it would still handle writing the UF2 file correctly. >>>>>>>>>>> >>>>>>>>>>> Theo >>>>>>>>>> >>>>>>>>>> My Pi guy says that you can only write one file, and the act of >>>>>>>>>> writing that file wipes anything that was there before. So the flash >>>>>>>>>> probably doesn't have a file structure, and the USB memory-stick write >>>>>>>>>> is, well, a sort of cheap trick. >>>>>>>>>> >>>>>>>>>> That's workable, if inelegant. We can pack everything we need into >>>>>>>>>> that one big file and users can upgrade box code in the field pretty >>>>>>>>>> easily. >>>>>>>>>> >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> And it gets wiped when new code is uploaded >>>>>>>>> >>>>>>>>> >>>>>>>>> It is an area I will have to tackle for one project tho. >>>>>>>> >>>>>>>> Yes, writing to flash from the running application is nasty. >>>>>>>> >>>>>>>> We have to calibrate each box. We'll store the prototype calibration >>>>>>>> table inside the big flash image. At factory test, we'll grab that, >>>>>>>> edit it for this particular unit, and save it to a small SPI eeprom >>>>>>>> chip. That costs 24 cents and one chip select pin. >>>>>>>> >>>>>>>> My guy says that there are a few magic integers at the start of the >>>>>>>> UF2 file that identifies it, well, as a UF2 file. That confirms that >>>>>>>> the Pico flash doesn't have a file structure, it just stores one giant >>>>>>>> chunk of stuff starting at the start. >>>>>>>> >>>>>>>> It's Windows who lies about it acting like a USB memory stick that >>>>>>>> stores files. >>>>>>>> >>>>>>>> We did consider saving the real cal table at some fixed physical >>>>>>>> address near the end of the flash , on the theory that nobody will >>>>>>>> ever write a bootable image that big. That might work. >>>>>>>> >>>>>>> That seems to be the case. >>>>>>> >>>>>>> I looked into it enough to see that it would be possible to store NV >>>>>>> data in a high part of the flash. >>>>>>> >>>>>>> I think that the runtime provides access to a memory location that >>>>>>> indicates the end of the uploaded flash image, so in theory flash above >>>>>>> that is free to write, with the proviso it has to be done in large >>>>>>> blocks on specific address boundaries. >>>>>>> >>>>>>> All this is at least Pi Pico specific anyway. >>>>>> >>>>>> We're using the RP2040 chip, so will have a huge flash chip. We will >>>>>> sometimes store an FPGA config file that could be too big for the 2 >>>>>> MByte part on the Pico. >>>>>> >>>>>> >>>>>>> >>>>>>> Will keep me busy through the dark winter days...:-) >>>>>> >>>>>> Storing anything in high flash still has the problem that you can't >>>>>> run flash-cached code while the write is going on, unless you are very >>>>>> careful. >>>>>> >>>>>> >>>>> >>>>> It?s good to have a warm relationship with your linker mapfile. ;) >>>>> >>>>> Cheers >>>>> >>>>> Phil Hobbs >>>> >>>> Interrupts might get nasty, demanding swaps into the flash cache when >>>> the flash is busy writing. >>>> >>>> >>> >>> That’s where the mapfile comes in. Assuming that you can update one flash >>> page while updating another, that is. >>> >>> Cheers >>> >>> Phil Hobbs >> >> The RP2040 usually executes code out of a small 16 Kbyte sram that >> caches code from the flash, so users don't have obvious control over >> which flash pages are being read. To write to flash, one has to do >> things to ensure that nothing needs to read the flash chip for the >> duration of the write. >> >> That's a big hassle to save 24 cents of SPI flash chip off to the >> side. > >And the price of a circuit board! The boards in this series are about 17 square inches, usually 6 layers, and we'll have parts on both sides. The CPU and big flash and small flash would fit inside the footprint of the Ethernet connector! And cost a lot less! --- SoupGate-Win32 v1.05 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3) .