Subj : Re: RP2040 reset idea To : tnp@invalid.invalid From : john larkin Date : Sun Sep 22 2024 10:46:20 XPost: sci.electronics.design On Sun, 22 Sep 2024 09:32:10 +0100, The Natural Philosopher wrote: >On 21/09/2024 20:56, 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. >> >I think the recommended technique is to disable all those and suspend >any other threads that might be active or write only single threaded code I think we'll go bare-metal on both CPUs, no RTOS, but we'll still have interrupts so can't guarantee that all the code we need is in the tiny cache. A separate small eeprom simplifies things. --- SoupGate-Win32 v1.05 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3) .