In-field firmware update of SC20100S?

I know Gus already confirmed this is not possible given the current architecture…but I’ve been pondering.

My program is relatively compact (35k .exe generated in Debug config) and in total with libraries shouldn’t take up anywhere near the 1 MB of internal RAM on the chip.

I’m not familiar with the internal working of how to in-field update process works (obviously…) But would it be technically possible to flash the chip from internal RAM for small program sizes like this? With the big asterisk that this would be a new feature and require new work I’m sure…but I’m curious if it would be technically possible in the future.

I ask because I don’t need the extra pins of the BGA package, don’t need the external RAM for the program, and don’t want the complexity of BGA assembly or increased BOM costs associated with all of the above. But firmware updates would be very useful, especially with what I expect will be evolving firmware revisions in the near future…

You can update your application. You just can’t update the firmware, the TinyCLR OS.

That doesn’t answer the question though… Given that the total RAM required to store the firmware, program and libraries is dramatically less than the internal RAM, is there a technical blocker as to why the firmware can’t be updated from the internal RAM? Or just a prioritization of features / human bandwidth blocker?

TinyCLR OS is over a megabyte! It is not small.

Created an issue for this https://github.com/ghi-electronics/TinyCLR-Libraries/issues/589

1 Like

Ahh I see… I was neglecting to count the size of the firmware itself.

Do you have any particular quad SPI chips in mind or that you’re familiar with? As always with the devil is in the details and if your team is already familiar with or eyeballing a specific make I can just drop an unused footprint on my PCBs and cross my fingers :slight_smile:

The chip page on docs lists the exact part number you should use.