Why can I read and write flash memory beyond 0x0810 0000 in an STM32F427VG chip with only 1MB of flash?

[E P]

Hi all,

I have a project running on an STM32F427VI that makes some specific use of the dual-bank flash, both for storing certain configuration parameters and for a custom bootloader.

It's great, but I don't get anywhere near using the full 2MB of flash memory, so given difficulties in finding chips I'd like to be able to use the STM32F427VG chip, with 1MB of flash, instead.

I see that if the DB1M option bit is set, I can use the flash of the 1MB chip in dual-bank mode with a layout similar to the 2MB chip, which is perfect.

So I got a 1MB chip and soldered it to the board. For fun, I programmed it with my existing bootloader and application and ... it worked?

This is surprising, because the bootloader process uses flash that is beyond the 0x0810 0000 (1MB) boundary. If I connect to the chip using ST-LINK, it correctly shows the 1MB flash size, and if I go to "Erase Sectors ..." it correctly shows the 1MB single-bank flash layout. But in my code, at various times I erase flash sectors > 11 (which don't exist given that the DB1M option is in its default state of not being set) and even FLASH_SECTOR_23 (which doesn't exist in any documented configuration of this chip). Even more surprising, using ST-LINK I can read and write to flash addresses beyond the 0x0810 0000 boundary.

My existing code assumes the memory layout is as shown in Table 6 of RM0090, with 24 total sectors in two banks (0x0800 0000 - 0x080F FFFF, and 0x0810 0000 - 0x81F FFFF). For erasing flash, I use the FLASH_SECTOR_* macros in HAL, and hardcoded addresses. So if I look at Table 9 of the same document, my hardcoded addresses should be all wrong, and at least some of my flash sectors shouldn't exist. First I thought that the HAL code was doing some translation magic, but I don't see it anywhere, and ST-LINK also happily shows me the contents of flash address ranges that shouldn't exist. I also note that address 0x1FFF 7A22 of the VG chip correctly shows 0x0400 for the flash size.

I am assuming that either a) I am going insane, b) I am mistaken somehow, or c) I have won the ST lottery and received a bonus extra 1MB of flash in my 1MB chip, but I am hoping that the answer is (b) and someone here can point out where I am wrong.

Thanks!

[gbm]

Not a surprise at all. The easiest way to differentiate STM32F103C8T6 from a Chinese clone is to check for 128 KiB Flash. 😉

[Tesla DeLorean · Accepted solution]

They make one die, as time on the tester is a significant throughput cost they opt to test a subset to achieve price stratification.

[Tesla DeLorean]

Licensing and export options also have Ethernet and Hash/ Crypt​ disabled on 427 vs 439

[E P]

Good points by @gbm​  and @Community member​ ... and I get that it's common practice to use a common die and then disable features for different product lines, or downselect based on inline test failures. But I mean I guess I would have assumed they'd blow a fuse or something so that the memory isn't actually usable? Like I have code compiled for an STM32F427VI using flash that isn't available on the STM32F427VG, and it works perfectly.

Aside from leaving a wide, inviting window open for counterfeiters, why pay $2 extra for the VI chip if the VG chip is literally the same thing with a single register factory-programmed to a different value? ST has 149 chips in the STM32F4xx line; there are at least 20-30 whose only differentiation is 1MB flash vs 2MB ... are people (such as me) paying for the 2MB chip just paying an idiot tax? (this is aside from the fact that I ended up not needing all that flash anyway, cut me some slack here y'all)

Eh, maybe I'm just asking too much.

[E P]

Addendum - and OK I know there are a lot of feelings about HAL on the community here, but after scouring code for an unreasonably long amount of time I find absolutely no distinction between the 1MB and 2MB versions of the chip. I find a single macro that does any sort of bounds checking on flash write addresses, and it's simply bounding the input between 0x08000000 and 0x081FFFFF, so 2 MB. The chip itself doesn't seem to enforce anything either, and despite not having the DB1M option set, behaves as if it's in dual-bank mode. Now I'm actually concerned that if I change my code to operate as indicated in the reference manual, it might not even work right. Like yeah, OK, make one product and market it differently, but are they seriously just relying on the honor system here?

[AScha.3]

no, is no tax. 😉

you pay for 1MB test + warranty .

other exra flash may work 100% - your lucky.

or has some errors...can be also.

so if need 100% working 2MB - pay the extra.

[Tesla DeLorean]

Additionally the tested flash size is fused into OTP

Flash size in KB as 16-bit word at 0x1FFF7A22

https://www.st.com/resource/en/reference_manual/dm00031020-stm32f405-415-stm32f407-417-stm32f427-437-and-stm32f429-439-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf

[E P]

Yes, and this register is correct on the VG chip (as I mentioned earlier) but why do this but not open a fuse somewhere that actually removes access to the supposedly unusable sectors (8-11 and 20-23)?

More critically, per table 7 of that document, in single-bank mode, it just gives access to sectors 8-11 and switches off the second 1MB bank - so there's even overlap on what chunks of flash get used. Also, in addition to the 1 vs 2 MB question, the single vs dual bank distinction seems to only exist on paper, since it's literally the same flash, and even with the bit turned off (default setting) it behaves as if it's dual bank (because it apparently is). I'm struggling to see why ST went through the trouble of creating product variations that literally only exist in the documentation.

Maybe this is why I'm an engineer and not a business person.