STM32F10x Flash size mismatch

[Matthias.U]

I have a bunch of Blue Pill boards I'm re-animating (ye olde chippe shortage, y'know). Attacking them with stm32flash reports a flash size of 128 kBytes. On the other hand, 0x1FFFF7E0 contains 0x40, indicating 64 kBytes of flash.

Now, which of these is correct? if it's the former, how can the code running on the board discover that fact?

[Peter BENSCH · Accepted solution]

Welcome, @Matthias.U​, to the community!

It's not about what the STM32Flash reports, but what is marked on the STM32 (if it is a real one, because fakes are very often used on Blue Pills). It may be that a chip with more Flash is inside, but only the labeled amount was checked. Only for this amount of Flash we guarantee full functionality in the entire temperature range and under all test conditions specified in the data sheet. Anything that is used beyond this is the responsibility of the user without any guarantee.

Good luck and regards

/Peter

[Matthias.U]

Thanks. I suspected as much. I have a test program that should (AFAIK) test for all known signs of fakes and doesn't find any, so this should be yours.

However, I'd still like an answer to (the second part of) my question – is there any way to discover the additional flash storage's existence from the inside, so to speak, without simply writing something to that flash and checking if it "takes"?

[Peter BENSCH]

Simple answer: no.

[Matthias.U]

Too bad.

Thanks for the prompt and concise reply, even if I happen to not like it. :\ Fortunately I only have to do this test write once.

[Peter BENSCH]

The use of unchecked flash is not only the responsibility of the user, but also a nogo in real industrial applications: you don't even know what the next chip or delivery contains. It is by no means always the case that there is physically more flash in an STM32 than the marking indicates as tested. So it can look completely different for the next batch.

Why should ST Flash report back whose function is not guaranteed?

This is not recommended even for hobbyist purposes, because bit errors can occur at any time - and the maker may then scold the manufacturer for forgetting that he is using unofficial, unspecified functions.

If the problem is resolved, please mark this topic as answered by selecting Select as best. This will help other users find that answer faster.

/Peter

[Tesla DeLorean]

The Cortex-Mx should Hard Fault if you touch out-of-bounds memory, ie address not fully decoded.

So a try-catch type implementation should be able to probe the presence of memory.

The chip die can also be determined, this lets you know if the part was physically defused from masks with 128, 256, 512 KB or 1 MB, establishing the upper ceiling for a given part, the value written to OTP reflects the amount tested, as testing the array adds considerable time to the IC test phase, and reduction in this time can allow for stratification in pricing and multiple SKU.