2025-12-06 10:23 AM - last edited on 2025-12-08 3:18 AM by mƎALLEm
I think it doesn't have an impact and you just get extra pins (e.g. extra SPI controllers becoming accessible) if going say 100 to 176. But it's not clear...
IOW, will existing code run exactly as before?
Isn't the silicon identical and they merely bond out the extra pins on the bigger packages?
Solved! Go to Solution.
2025-12-08 3:18 AM
@PHolt.1 wrote:
I wonder if running VGT6 code on say an IGT6 might create floating signals internally.
As said previously, they absolutely have the same die inside.
VGT6 -> 100 pin package
IGT6 -> 177 pin package
From the datasheet:
G means 1024KB of flash memory.
So migrating from VGT6 to IGT6 with a code made for VGT6 is doable.
Migrating 417 to 437 is another question.
2025-12-06 10:37 AM
If the part number is the same except for the package, yes the AF mapping will be identical. This is covered in the datasheet. One AF mapping table for the entire family.
2025-12-06 10:40 AM
Hello @PHolt.1
I think if both MCUs have the same sub device name (F401, F407,..) (same datasheet) the AF should not be changed and the same code (made for the smallest package) should run on both MCUs. For different subfamilies, I think more verification is needed.
Best Regards.
II
2025-12-06 12:41 PM
Hello;
" does going up a package pin count impact pin AF mapping?" -> Absolutely not.
All packages of the same part number have the same die inside. Common GPIOs between the different packages have common AFs. Extra GPIOs have more AFs, more SPI AFs, TIMs AFs, etc ..
2025-12-06 4:03 PM
Depends on specific model, but many share the same die, you can check..
The muxing is fairly consistent but will be in the data sheet. More pins, more escape options.
F407, F401 and F412 are all different die.
2025-12-07 12:15 AM - edited 2025-12-07 12:29 AM
OK I was a bit ambiguous in using "4xx" which implies different CPU chips.
I was really asking if going say 32F417 QFP100 to QFP144 to QFP176
32F417VGT6 to 32F417ZGT6 to 32F417IGT6 (100 to 144 to 176)
the VGT6 code will just run.
Obviously if by going to a bigger package you expose new GPIO etc then these need to be taken care of on the PCB. AIUI all unconfigured GPIO comes up as inputs, but if you expose other-functional pins then this is not so.
I wonder if running VGT6 code on say an IGT6 might create floating signals internally.
Then you get the interesting topic of the 32F437 which is an almost perfect superset of the 417 and (apart from the Vbat measurement ADC channel) is 100% software compatible. I use it for the extra 64k RAM (I get the device ID and on the 437 move the general stack 64k higher up, and fix up the Vbat ADC channel, but run the 417 code otherwise, with the only place where the 437 is specified being the ST Utility production programmer) but it has six SPIs instead of three and the QFP144 package should expose at least one of these.
2025-12-08 3:18 AM
@PHolt.1 wrote:
I wonder if running VGT6 code on say an IGT6 might create floating signals internally.
As said previously, they absolutely have the same die inside.
VGT6 -> 100 pin package
IGT6 -> 177 pin package
From the datasheet:
G means 1024KB of flash memory.
So migrating from VGT6 to IGT6 with a code made for VGT6 is doable.
Migrating 417 to 437 is another question.
2025-12-08 4:42 AM
What is interesting is that the 437 is an extremely close superset of the 417.
2025-12-08 4:46 AM
@PHolt.1 wrote:
What is interesting is that the 437 is an extremely close superset of the 437 .
I suggest to close that thread and start another one for 437 vs 417 as the original question has been answered.
Thank you.
2025-12-08 7:53 AM
Happy to start a new thread but not sure how to frame that question to get a good answer.