Enabling extra RAM or peripherals on microcontrollers

[peter-h]

It seems pretty obvious that many manufacturers sell the same silicon under different P/Ns and at different prices.

They usually have undocumented "fuses" to enable features but in some cases they don't even bother (today's post about some chinese arm32 having 4k RAM on a "2k" device).

For example I would not be surprised if a STM32F437 and 417 are the same, with some factory programming to enable the extra 64k RAM on the 437.

It's always gone on e.g. the Hitachi H8/323 was sold for extra in the 3.3V version but many years later Hitachi told me the 5V silicon is the same. Maybe testing differs... but some of the H8/300 parts were also identical-chip and factory-programmed.

It's an interesting area to explore.

[coppice]

Developing new dies is expensive, so a single MCU die is typically spun to make a bunch of different parts. Its not just the design effort. Mask sets cost a fortune for finer geometries. If one variant hits a massive volume they may go back and produce an optimised die for that part. However, when the decision comes between committing a development team to an optimised respin, or making a new part to address new markets, the optimised die has a habit of losing out. You might be amazed at the range of device complexities (e.g. memory sizes) spun out from a single die. Most dies are fuse programmed at test time, so there is nothing much you can do about extracting more resources from the device as it is sold you, unless there is a bug.

[langwadt]

Developing new dies is expensive, so a single MCU die is typically spun to make a bunch of different parts. Its not just the design effort. Mask sets cost a fortune for finer geometries. If one variant hits a massive volume they may go back and produce an optimised die for that part. However, when the decision comes between committing a development team to an optimised respin, or making a new part to address new markets, the optimised die has a habit of losing out. You might be amazed at the range of device complexities (e.g. memory sizes) spun out from a single die. Most dies are fuse programmed at test time, so there is nothing much you can do about extracting more resources from the device as it is sold you, unless there is a bug.

A place I worked +20 years ago was bitten by that once. Someone had made a mistake and used a some ram that was only supposed to be there in a bigger part, it worked just fine since it was the same die for both parts

Until at some point the volume got so large that the manufacturer made an optimized die for the smaller part we used, then that extra ram wasn't there anymore and production panicked because nothing worked anymore ..

[SiliconWizard]

Sure, this is a pretty common approach (and for good reasons) for ICs due to cost of manufacturing new chips with different dies. This has been done for decades.
Sometimes you can find ways to access the disabled sections of some IC, most often it's not possible.
Of course by doing so you lose any support from vendors, so while it can be fun to explore as a hobby, it's rarely a good idea for any commercial product.

One example I have in mind with absolutely zero hardware limitation is the Lattice ECP5 12F. It's the exact same die as the 25F (which has double the LUTs), the whole 25k LUTs are accessible on it, there is no fuse or whatever. The only difference is the chip ID. Lattice Diamond does enforce the limitation based on the chip ID, but that's a purely software thing. Using Yosys and nextpnr, you can use the 25K LUTs on a 12F (and it's nearly half the price.)

[hans]

I doubt the F417 and F437 are same die. Some peripherals are renewed and there is some time between releases.

They can turn off peripherals, memory, etc. to make them functionally different. But if it's really the same die, they can't really change its [scaling] power consumption (e.g. uA/MHz for same peripheral or some static power). If you compare those they look to be different chips, where the F417 seems to consume a bit more peripheral power. The FSMC and FMC controllers are also very different. Also stop, standby currents etc. seem to be about 10% better on F43x.

The F43x supports SDRAM, which was quite a hype the STM32F4 line. There is about 24 months between these devices.

Obviously they are not going to make different dies for the different memory, packages and 'the options list' (peripherals, e.g. F405 vs F407, or F42x vs F43x), as these devices share the same datasheet. But in this case I don't think these chips (F417 and F437) share the same die.
But maybe others do.

[peter-h]

Some peripherals are renewed

In what way?

Another way to look at this is the hypothesis that after the 437 came out, the 417 was changed to use the 437 silicon. If the spec improves, no need to change the DS

I recall Xilinx did that, greatly speeding up the XC3064, without changing the specs, and breaking a lot of "less than fully synchronous" designs. Maybe a XC3090 with some config "fuses".

I say this because, a couple of years ago, I built a few boards with the 437 in error, and they all work exactly the same. UARTs, SPI, etc.

The counter argument to the above is that there is an official difference in the ADC mux to measure the RTC battery voltage.

[eliocor]

based on my experience the STM32L431 and the STM32L433 are the same chip (433+=USB support)

[newbrain]

Many here, me included, have ST-link V2 clones that use an STM32F101 MCU, supposedly with no USB.
They work as (not) expected.

Same goes for 32/64 kB memory on many BLue Pill (STM32F103, when you are lucky )

[DavidAlfa]

List of dies:
https://www.mikrocontroller.net/attachment/443532/stm32-families.txt

So you can get the cheapest mcu with the same die and use the extra flash and peripherals (But not guaranteed to be functional), however to this day I didn't found any way to unlock the extra ram, it always causes hard fault.