RP2040 reset idea

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.

Will keep me busy through the dark winter days...:-)

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.

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

Our biggish sine lookup table could be plopped into SRAM too, to reduce thrashing.

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.

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

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.

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.

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

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

And the price of a circuit board!

That I didnt know. And is very useful information.

Not had any issues simply drag and dropping to an auto mounted image

UF2 images are over 600k.

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!

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.

I'm a circuit designer! I design boards.

I was going to plop a Pico on my boards, as a component, but it's big and has the small flash and the USB connector is awkward, so we'll solder the CPU and flash and such to our board.

Can't disagree about that.

We will use an FPGA on some products, and store the big uncompressed configuration bitfile on the same flash.

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.

--druck