RP2040 reset idea

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.

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 switch state on the BOOT- pin after a long (5 second?) reset pulse, but that would mean a slow start on each power on.

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

Thats' what my PICO powered thermostats have. For the onboard button though 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.

At a brief glance, yes, but I donbt see why a simmle disconnect power 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, Can always leave it out later

Asserting BOOT- (or pushing the button on the Pico board) at the end of reset should launch it into boot mode. On the Pico board, asserrting RESET- is done by cycling the power.

My user might have to remove all three power sources (PoE, 24 volt wart, USB) to force a reset, if we did the boot button like the Pico does.

My circuit doesn't delay a normal powerup. That's dominated by the roughly 200 msec reset generated by the MAX809 after the 3.3 supply stabilizes.

I don't think the 10u cap will weld the contacts of the pushbutton.

If BOOT- is low at the end of reset, it powers up in USB memory stick mode. I don't think that wipes the files stored in the big serial flash.

There are three potential power sources to disconnect, and I don't really want a power switch.

The schmitt adds way under a tenth of a per cent to the board area and the cost, so may as well leave it in.

Probably not weld, but destroy the plating. The peak current is very high. A 100R SMD resistor is not that expensive...

Arie

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

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.

It's a pretty small box.

Update:

The Pico only allows one file to be saved to the flash using USB memory-stick mode.

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.

The Pi tools support packing a bunch of things into that one file, including the executable for Alice, namely CPU0. Alice takes over and loads Bob, CPU1, and can access other components of the big file.

Power cycling, normal or into USB memory stick mode, does not wipe that big file.

There's no simple way to examine the components of the big file, other than to ask Alice. Alice knows.

All that is based on experiment.

What if you try it from Linux?

Unlike Windows, Linux is less prone to lie about things.

I just tried it using an RP2350 connected to a PC running Linux Mint Mate edition. I can copy files to the 2350 file system using either the GUI or command line and they give the appearance of being copied successfully. I can read them back. However, if I eject the USB drive and restart the RP2350 processor the files have gone away. So either they are being cached in the PC or they are only transiently stored.

John

sure it's not 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.