Code changes needed for drop in replacement of MCU's with more flash

[DJC]

Say, I have a STM32L431RB (128k,64k) on a board design.

This is the lowest flash size on the 6 chips on the STM32L4x1Rx 64pin variety.

It certainty looks like I can drop-in any of the larger flash/ram chips as the pin outs all look the same.

But do I need to actually rebuild the binary for each variant?

For example the STM32L431RC is exactly the same, but with more flash, while the 451 and 471 variants seem. Can it take the binary for for a STM32L431RB.

Has anyone tried this?

I ask this mostly to see if I can be a bit better protected against supply chain shortages in the future.

One tricky area for me might be in-field upgrades and tracking of which variants are going into which boards.

[Tesla DeLorean]

Firmware should be able to determine part (die) and tested flash size.

Some parts use the same die. I use L432RB, same die used for L432RC, both have 256KB physically.

You'd perhaps look at the startup.s files and diff them, this is where model level differences and incompatibilities would be most apparent.

[DJC]

Sorry, I don't understand what you mean by "die" and "tested flash size".

(looking up "MCU DIE", brings up lots of Marvel stuff 😅 )

Until now, I was under the impression that one builds firmware for a specific target and its pretty much assumed that the target MCU will be the correct one.

Are you saying that it's possible for a single firmware binary to adapt its behavior based on an underlying check of the MCU?

ie:

if L431RB do THIS,

if L431RC do THAT

Also, as far as I can see there is no L432RB or L432RC.

[TDK · Accepted solution]

You don't need to change the firmware if it fits in the smaller flash size. The same exact code will run on both chips just fine. No changes necessary.

You can read the FLASH_SIZE register to determine how much flash is onboard.

[Tesla DeLorean]

Wafer is filled with multiple identical die, https://en.wikipedia.org/wiki/Die_(integrated_circuit)

KB/KC

https://www.st.com/resource/en/datasheet/stm32l432kc.pdf

These share a common die, with 256KB on them, if they test half of it they can test twice as many chips in an hour, creating price stratification. ie appearance of different values/costs to fit pricing targets of customers with varying requirements/needs.

>>Are you saying that it's possible for a single firmware binary to adapt its behavior based on an underlying check of the MCU?

Sure, I've built firmware for a range of F4 parts, that check the chip type, set clocks and PLLs based on max speed (84, 100, 168, 180 MHz, etc), and size of heap from available RAM on specific devices. Then use dynamic allocation at start-up rather then large static allocations.

One could create a vector table on-the-fly, or have multiple firmwares sharing common code sections/blocks