"OTP" memory comments and request

[gahelton1]

I have a project (joystick controller) that requires a small amount of non-volatile memory (10 to 16 bytes) for calibration data. Presently, I am using a STM32F4 series micro for this project. Although it's a bit overkill, my initial plan was to use a sector of flash to store the calibration data, but it turns out that the sector size on the part I'm using is 16K !  That's a pretty big waste of flash for a few bytes of non-volatile storage. So, I took a look at OTP. While OTP would potentially work without wasting lots of memory, by definition, it's One Time Programmable. I anticipate that the joystick may need to be re-calibrated occasionally, so the present way OTP is implemented is not very useful without jumping through some hoops.

So here is what would be nice.

A user flash area (512 bytes would be just fine for most applications) that was divided into blocks just as the existing OTP memory is. The difference would be that until the lock bit(s) were set on a block, the memory would remain programmable and erasable. However, once a lock bit is set on the block, that block would become permanently locked, and could not be erased (not even with mass erase operation). This could be implemented by making the lock bits non-erasable. Once locked, that's it !  In my opinion, this would be the best of all worlds. Non-volatile user flash area when you need it, OTP when you need it. Of course, you could have both by only locking the blocks that need to be OTP (areas like serial numbers, etc).

Of course, one could always add an external EEPROM, but my request seems like a relatively simple thing to implement for those who don't need a large amount of NVM.

Everyone please comment. Maybe we can get this a feature on future versions.

Thanks,

Greg

[Tesla DeLorean]

16KB out of 1MB, probably not going to write that much firmware for a joystick.

Best to use the 16KB sectors toward the front of FLASH than the 128KB deeper in. You can journal the content to avoid erasure as long as possible.

You will need bootable code in the first 16KB sector as that's where the MCU expects it to start 

The F4 part is not going to be changed, look perhaps at the L1 or L0 parts for EEPROM, or some of the other parts with small uniform sized sectors.

[Pavel A.]

>  the sector size on the part I'm using is 16K !  That's a pretty big waste of flash for a few bytes of non-volatile storage

Do you have other plans for this 16K? If not, it will be wasted anyway.

[gahelton1]

Hi Tesla and Pavel. Thanks for the replies. While it is true that that if 16K sector wasn't used for anything else that it's not a waste. Also, I wouldn't expect an immediate change to a series of parts.

With that being said, I have been too close to the code limits too many times (once is really too many) to toss out 16K. Getting a larger part isn't always an option.

So what I'm asking is for you to do, is to close your eyes, and dream of an improved part where you had both re-programmable, non-volatile storage for parameters that "might change" , AND permanent non-volatile storage that can "never change". Both of which are selectable by the programmer - for future versions of course.

Thanks.

[Nikita91]

I close my eyes and dream to very small 8bitters like ATmega with 2KB EEPROM...

For a joystick, look at G0 with uniform 2K flash sectors...

[Pavel A.]

I don't need to close my eyes to imagine a STM8 🙂 Still keep few of them in the drawer.

If this feels better to you, don't give whole 16K sector for the data. You can use un-programmed space in any sector (write after the last location programmed by CubeProgrammer etc., use journaling to avoid erasing sector)

[gahelton1]

Wow. As Rodney Dangerfield would say, "This is a really tough crowd." I suppose my dream is lost (for now) Well, so be it. But I see a day in the not too distance future where ATmega's (I've used a bunch of them), and STM8s won't be manufactured anymore. Just no reason to.  Same is true of the other 8 bitters - Microchip PICs included. Economies of scale and cost says no. Not when you can get a 32 bit machine to do the job for the same or less money. The manufacturers are not going to build an 8 bit machine for 1/4 of the price of a 32 bit machine, so price is not much of a factor. I know they are still around, but I wonder for how long ? I left the 8 bitters years ago for ARM base machines, and haven't looked back except to reminisce about how I didn't have enough memory, or the machine wasn't quite fast enough, or how I had to jump through hoops to get a task done - and how GLAD I was that I didn't have to wire up a whole board of discrete logic to do it. Strive for constant improvement, and don't settle for the status-quo. I'll get off the soapbox now. Thank you for your comments. I'll be back, but not on this subject.

[Pavel A.]

Just get yourself another dream, there are piles of them waiting for good handlers.

[Andrei Chichak]

Or tag a very small FRAM chip onto the SPI bus. It doesn't consume any of your FLASH, isn't volatile, it's really small, it's external, needs a board modification, pretty expensive when you think about it, and lets you dream of the day when a small amount of FRAM is included in the processor.

For now, add a battery and bring up the NVRAM in the RTC.

[Pavel A.]

But ST already has EEPROM or OTP in several MCU models, even in STM8. Out of curiosity, why not in more/all models? It looks like very useful feature. Is it hard to make?