The RP2040 has a cool mode where it can be made to boot up with the
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board;
if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while reconnecting power.
Some of my customers also want to lock a box such that it's impossible
to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
https://www.dropbox.com/scl/fi/bbhdy053xsdzv77g0brc5/B-box_Reset_Button_3.jpg?rlkey=40ozzdvczf4z8625u8i081a9b&raw=1
Does that look like it will work? The paranoid customer can pave over
the two holes, and even the end-plate screws, with an official-looking sticker.
Schmitt trigger U3 is unfortunate and likely unnecessary, but it
insures against a low-probability hazard.
The RP2040 has a cool mode where it can be made to boot up with the
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board;
if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while reconnecting power.
Some of my customers also want to lock a box such that it's impossible
to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
https://www.dropbox.com/scl/fi/bbhdy053xsdzv77g0brc5/B-box_Reset_Button_3.jpg?rlkey=40ozzdvczf4z8625u8i081a9b&raw=1
Does that look like it will work? The paranoid customer can pave over
the two holes, and even the end-plate screws, with an official-looking sticker.
Schmitt trigger U3 is unfortunate and likely unnecessary, but it
insures against a low-probability hazard.
The RP2040 has a cool mode where it can be made to boot up with the
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board;
if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while reconnecting power.
Some of my customers also want to lock a box such that it's impossible
to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
https://www.dropbox.com/scl/fi/bbhdy053xsdzv77g0brc5/B-box_Reset_Button_3.jpg?rlkey=40ozzdvczf4z8625u8i081a9b&raw=1At a brief glance, yes, but I donbt see why a simmle disconnect power
Does that look like it will work? The paranoid customer can pave over
the two holes, and even the end-plate screws, with an official-looking sticker.
Schmitt trigger U3 is unfortunate and likely unnecessary, but it
insures against a low-probability hazard.
On 17-Sept-24 10:58 am, john larkin wrote:
The RP2040 has a cool mode where it can be made to boot up with the
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board;
if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while
reconnecting power.
Some of my customers also want to lock a box such that it's impossible
to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
https://www.dropbox.com/scl/fi/bbhdy053xsdzv77g0brc5/B-box_Reset_Button_3.jpg?rlkey=40ozzdvczf4z8625u8i081a9b&raw=1
Does that look like it will work? The paranoid customer can pave over
the two holes, and even the end-plate screws, with an official-looking
sticker.
Schmitt trigger U3 is unfortunate and likely unnecessary, but it
insures against a low-probability hazard.
If the board needs to be powered up, rather than just reset, while the
button is pressed, then how does your solution work? If not, then why is
the fact that there are three power supplies relevant?
Sylvia.
On 2024-09-17 04:58, john larkin wrote:switch state on the BOOT- pin after a long (5 second?) reset pulse, but that would mean a slow start on each power on.
The RP2040 has a cool mode where it can be made to boot up with the
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board;
if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while
reconnecting power.
Some of my customers also want to lock a box such that it's impossible
to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
https://www.dropbox.com/scl/fi/bbhdy053xsdzv77g0brc5/B-box_Reset_Button_3.jpg?rlkey=40ozzdvczf4z8625u8i081a9b&raw=1
Does that look like it will work? The paranoid customer can pave over
the two holes, and even the end-plate screws, with an official-looking
sticker.
Schmitt trigger U3 is unfortunate and likely unnecessary, but it
insures against a low-probability hazard.
I used the same idea, but with less hardware. The switch triggered (RC differentiator) the reset pulse and the MCU senses the state of the switch after the reset pulse trailing edge. I used the bootloader code for that timing. The RP2040 could sense the
I think your idea would work OK, just a bit complex. Just NEVER short a cap with a switch (or relay) without a series resistor.
Arie
On 17/09/2024 03:58, john larkin wrote:
The RP2040 has a cool mode where it can be made to boot up with theThats' what my PICO powered thermostats have. For the onboard button though >Resetting is done by pulling the power.
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board;
if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while
reconnecting power.
Some of my customers also want to lock a box such that it's impossible
to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
The point is that if you do power up with the button pressed, you wipe
the entire FLASH RAM I think.
https://www.dropbox.com/scl/fi/bbhdy053xsdzv77g0brc5/B-box_Reset_Button_3.jpg?rlkey=40ozzdvczf4z8625u8i081a9b&raw=1At a brief glance, yes, but I donbt see why a simmle disconnect power
Does that look like it will work? The paranoid customer can pave over
the two holes, and even the end-plate screws, with an official-looking
sticker.
switch in addition to the onboard switch wouldn't be as easy.
Once you start laying out a board, put everything on it you may need,
Schmitt trigger U3 is unfortunate and likely unnecessary, but it
insures against a low-probability hazard.
Can always leave it out later
On Tue, 17 Sep 2024 10:49:58 +0200, Arie de Muijnck <noreply@ademu.nl>...............
wrote:
I think your idea would work OK, just a bit complex. Just NEVER short a cap with a switch (or relay) without a series resistor.
I don't think the 10u cap will weld the contacts of the pushbutton.
Some of my customers also want to lock a box such that it's impossible
to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
https://www.dropbox.com/scl/fi/bbhdy053xsdzv77g0brc5/B-box_Reset_Button_3.jpg?rlkey=40ozzdvczf4z8625u8i081a9b&raw=1
On 17/09/2024 03:58, john larkin wrote:
The RP2040 has a cool mode where it can be made to boot up with theThats' what my PICO powered thermostats have. For the onboard button though >Resetting is done by pulling the power.
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board;
if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while
reconnecting power.
Some of my customers also want to lock a box such that it's impossible
to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
The point is that if you do power up with the button pressed, you wipe
the entire FLASH RAM I think.
On 17/09/2024 17:09, john larkin wrote:
On Tue, 17 Sep 2024 11:07:17 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:
On 17/09/2024 03:58, john larkin wrote:
The RP2040 has a cool mode where it can be made to boot up with theThats' what my PICO powered thermostats have. For the onboard button though >>> Resetting is done by pulling the power.
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board;
if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while
reconnecting power.
Some of my customers also want to lock a box such that it's impossible >>>> to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
The point is that if you do power up with the button pressed, you wipe
the entire FLASH RAM I think.
My Pi guy verifies that entering boot mode doesn't change the contents
of flash. Power cycle and things run like before.
You had me worried!
Really?
I guess whenever I entered that mode it was to download fresh code...
In comp.sys.raspberry-pi john larkin <JL@gct.com> wrote:
Some of my customers also want to lock a box such that it's impossible
to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long
push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
https://www.dropbox.com/scl/fi/bbhdy053xsdzv77g0brc5/B-box_Reset_Button_3.jpg?rlkey=40ozzdvczf4z8625u8i081a9b&raw=1
Looks neat. But I wonder if there's a mechanical solution. eg give the >customer a loop to put a padlock through to lock the lid, and hide the boot >button behind, such that they can't press it without undoing the
padlock. Could even be something simple like a Kensington lock slot where >the boot button is deeply recessed in the slot - you have to stick a >screwdriver in the slot and can't do so if there's a lock inserted.
Of course that might cost more than your solution, so you can probably
ignore me :)
Theo
On Tue, 17 Sep 2024 17:21:36 +0100, The Natural Philosopher ><tnp@invalid.invalid> wrote:
On 17/09/2024 17:09, john larkin wrote:
On Tue, 17 Sep 2024 11:07:17 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:
On 17/09/2024 03:58, john larkin wrote:
The RP2040 has a cool mode where it can be made to boot up with theThats' what my PICO powered thermostats have. For the onboard button though
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board; >>>>> if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while
reconnecting power.
Some of my customers also want to lock a box such that it's impossible >>>>> to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long >>>>> push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
Resetting is done by pulling the power.
The point is that if you do power up with the button pressed, you wipe >>>> the entire FLASH RAM I think.
My Pi guy verifies that entering boot mode doesn't change the contents
of flash. Power cycle and things run like before.
You had me worried!
Really?
I guess whenever I entered that mode it was to download fresh code...
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.
If you copy a bunch of files into the flash, Windows will lie about
what's there, but there is really only one. If you disconnect the USB
cable and reconnect, Windows will show the one file.
On Tue, 17 Sep 2024 17:21:36 +0100, The Natural Philosopher <tnp@invalid.invalid> wrote:
On 17/09/2024 17:09, john larkin wrote:
On Tue, 17 Sep 2024 11:07:17 +0100, The Natural Philosopher
<tnp@invalid.invalid> wrote:
On 17/09/2024 03:58, john larkin wrote:
The RP2040 has a cool mode where it can be made to boot up with theThats' what my PICO powered thermostats have. For the onboard button though
USB port looking like a memory stick. That's great for software
installs or upgrades. The Pico board has a BOOT button on the board; >>>>> if the pico is powered up with the button pushed, it goes into that
boot mode.
But if I have a product (actually a family of products) in a nice
aluminum box, a user would have to remove the top cover, remove all
power sources (there can be three), and hold the button down while
reconnecting power.
Some of my customers also want to lock a box such that it's impossible >>>>> to write to any nonvolatile memory while it's in a secure area.
So here's an idea: a small hole in the box allows a toothpick or a
paper clip to push a button. A short push is a regular reset. A long >>>>> push is a memory-stick mode boot. We can have a rotary switch LOCK
hole too.
Resetting is done by pulling the power.
The point is that if you do power up with the button pressed, you wipe >>>> the entire FLASH RAM I think.
My Pi guy verifies that entering boot mode doesn't change the contents
of flash. Power cycle and things run like before.
You had me worried!
Really?
I guess whenever I entered that mode it was to download fresh code...
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.
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
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.
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:Definitely uf2 here.
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
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
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:Definitely uf2 here.
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
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.
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:Definitely uf2 here.
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
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.
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:Definitely uf2 here.
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
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.
On Sat, 21 Sep 2024 19:50:34 -0000 (UTC), Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
john larkin <JL@gct.com> 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 PhilosopherThat seems to be the case.
<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:Definitely uf2 here.
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
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.
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.
Its 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.
john larkin <JL@gct.com> wrote:
On Sat, 21 Sep 2024 19:50:34 -0000 (UTC), Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:
john larkin <JL@gct.com> 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 PhilosopherThat seems to be the case.
<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:Definitely uf2 here.
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
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.
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.
Thats where the mapfile comes in. Assuming that you can update one flash >page while updating another, that is.
Cheers
Phil Hobbs
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
In article <vclv4m$1he37$2@dont-email.me>,
The Natural Philosopher <tnp@invalid.invalid> 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.
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 PhilosopherThat seems to be the case.
<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:Definitely uf2 here.
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
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.
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.
On Sat, 21 Sep 2024 19:50:34 -0000 (UTC), Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
john larkin <JL@gct.com> 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 PhilosopherThat seems to be the case.
<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:Definitely uf2 here.
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
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.
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.
On Sat, 21 Sep 2024 20:46:52 -0000 (UTC), Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:
john larkin <JL@gct.com> wrote:
On Sat, 21 Sep 2024 19:50:34 -0000 (UTC), Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:
john larkin <JL@gct.com> 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 PhilosopherThat seems to be the case.
<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:Definitely uf2 here.
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
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.
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.
I guess the flash cache approach might trash IRQ latency. The flash is
4-lane SPI. I think we can tell the compiler to put the ISRs and some
bits of time-critical code into the bigger (256 Kbytes) SRAM.
Our biggish sine lookup table could be plopped into SRAM too, to
reduce thrashing.
On 22/09/2024 00:11, john larkin wrote:
On Sat, 21 Sep 2024 20:46:52 -0000 (UTC), Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:
john larkin <JL@gct.com> wrote:
On Sat, 21 Sep 2024 19:50:34 -0000 (UTC), Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:
john larkin <JL@gct.com> 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 PhilosopherThat seems to be the case.
<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:Definitely uf2 here.
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
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.
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.
Thats 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!
On 21/09/2024 20:56, john larkin wrote:
On Sat, 21 Sep 2024 19:50:34 -0000 (UTC), Phil HobbsI think the recommended technique is to disable all those and suspend
<pcdhSpamMeSenseless@electrooptical.net> wrote:
john larkin <JL@gct.com> 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 PhilosopherThat seems to be the case.
<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:Definitely uf2 here.
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
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.
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.
Its 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.
any other threads that might be active or write only single threaded code
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 PhilosopherThat seems to be the case.
<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:Definitely uf2 here.
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
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.
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.
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.
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.
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)...
[Massive snip]
Come on everyone, please edit down the previous messages to just the bit
you are responding to.
I don't have all day to spend scrolling.
| Sysop: | Coz |
|---|---|
| Location: | Anoka, MN |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 140:24:41 |
| Calls: | 166 |
| Files: | 5,389 |
| Messages: | 223,236 |
