"No update" FLASH

What CPU?

We use the RP2040 in a new product line, with a giant flash for the programs (dual CPUs) and for the FPGA config.

The Pi cpu has wonderful provisions for field code upgrades. It can't be bricked. So we can fix bugs or add features safely and easily, by email.

You'll only need to update it if you lack the capability to do so.

Dunno. We *used* to ship products with masked/OTP ROMs and the world didn't come to an end. Suddenly, no one believes in shipping *working* software! :<

By moving the application into RAM, you can limit the boot loader to the bare minimum to get the image *into* that RAM. E.g., TFTPc is only about 500 lines of code and /a well understood protocol/ so likely easy to "get right first time".

And, if you elide most of the options that the protocol supports, you can likely shrink this even more (you're designing a *product*, not a "commodity").

It's folks who want to store complex applications in FLASH that leave themselves open to having to reflash the images after delivery.

Today, it's common practice to ship products with out of date firmware. The idea is to buy the developers time to finish the software and maybe do some minimal testing. The end user is expected to upgrade the firmware and provide feedback so that bugs can be identified and fixed. In some areas, that works well. In other areas, not so well. As I vaguely recall, NASA likes to launch space probes with unfinished software:

But, that's because the firmware *is* the "operating software". One can argue that there is value to the user in this (he gets the product sooner) -- but by pushing costs onto the consumer (and hoping he doesn't actually *tabulate* those costs).

They have also had some amusing bugs in "released" software:

Mars Polar Lander: "A post-mortem analysis determined the most likely cause of the mishap was premature termination of the engine firing prior to the lander touching the surface, causing it to strike the planet at a high velocity."

Mars Climate Orbiter: "The primary cause of this discrepancy was that one piece of ground software supplied by Lockheed Martin produced results in a United States customary unit, contrary to its Software Interface Specification (SIS), while a second system, supplied by NASA, expected those results to be in SI units, in accordance with the SIS. Specifically, software that calculated the total impulse produced by thruster firings produced results in pound-force seconds. The trajectory calculation software then used these results – expected to be in newton-seconds (incorrect by a factor of 4.45) – to update the predicted position of the spacecraft"

I've taken this approach -- but, without "The Internet" and without altering the FLASH; just *load* the software from a local network store at EACH boot time. Not dicking with the FLASH means you don't have to worry about bricking it (and dispatching someone to the site to retrieve and recover the damaged item).