Re: RP2040 reset idea

On 21/09/2024 20:43, john larkin wrote:

On Sat, 21 Sep 2024 19:29:26 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:
 

On 21/09/2024 16:08, john larkin wrote:

On Sat, 21 Sep 2024 09:12:06 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:
>

On 20/09/2024 19:00, john larkin wrote:

On 20 Sep 2024 11:30:13 +0100 (BST), Theo
<theom+news@chiark.greenend.org.uk> wrote:
>

In comp.sys.raspberry-pi The Natural Philosopher <tnp@invalid.invalid> 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.
 

Oh. so you are rolling your own boards?
Nice. I wish I were younger sometimes...
Too big for 2MYBTE flash?  Wow.

 

>
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.
 

Yes, but in my case that is OK. Its configuration data set up on a 'once only' type basis during installation. And then very occasionally thereafter.
WORM - write once, read many.
And a single threaded code model. No worse than doing a floppy disk write in the foreground (remember  those days)...
--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.
- George Orwell