Why is STM32F427 revision 4 bootloader area empty?

[jpa]

We received chips labeled "STM32F427VGT6 990C8 VQ MYS 99 141 4".

Initially they failed to boot at all, but SWD debugger connects ok.

The option bytes had BFB2=1, causing system memory to be mapped at 0x00000000 independent of BOOT0 state. After changing that to BFB2=0, our firmware boots ok.

However the system bootloader does not work. The 0x1FFF0000 memory area reads all 0xFF bytes. It is as if the bootloader was never programmed in production line.

The device unique ID at 0x1FFF7A10 reads as 0x00330025 0x31315119 0x30333437

or as ASCII: "% 3 Q117430"

The flash size register at 0x1FFF7A22 reads as 0xFFFF.

What is going on? Are these some factory reject chips that have ended up in the supply chain, or has ST made a production mistake? Or is there some weird change in revision 4?

[Uwe Bonnes]

Did you get the devices from a reputable source?

[jpa]

They came through a reputable contract manufacturer, but I'm still trying to resolve where exactly they obtained the chips.

[Uwe Bonnes]

Does 0x1FFF0000 memory area really reads all 0xFF? Maybe the device was in lockup. Un- and repower and try again. Perhaps dump the whole 0x1FFF0000 to 0x20000000 area. Where starts the system memory to be programmed?

[Uwe Bonnes]

B.t.w., RM0090 does not talk about a Rev. 4, but Rev 3 and 5 are listed. Dubious!

[jpa]

Just out of interest, here is the 0x1FFF0000 to 0x1FFF8000 memory dump from revision 3 (working) and revision 4 devices. Reading past 0x1FFF8000 seems to cause access fault on both revisions.

Turns out the "empty" area on revision 4 does not read all 0xFF, but alternates between 0xFF and 0x00 somewhat randomly in 64 byte blocks. Probably production rejects that have ended up with some shady distributor.

https://jpa.kapsi.fi/stuff/other/stm32f427_rev3_sys_mem.bin

https://jpa.kapsi.fi/stuff/other/stm32f427_rev4_sys_mem.bin