Migrating in same STM32 family with only memory size difference

[RRice.1]

Are there ANY changes needed to code moving in between STM32 chips in the same family? I.e. form one STM32L412 to another STM32L412 with just different memory (128K to 64K). I have a working project but when I program it to new chip it successfully programs and verifies, but the chip does not work. No measurable outputs. Tried on several chips. Program memory size is not an issue.

[waclawek.jan]

Sometimes the model with "only less or more memory" is a surprisingly different chip.

This does not appear to be the case of 'L412. However, the 'L412 does have two different packaging variants in LQFP64, UFBGA64 and WLCSP36, with/without SMPS, distinguished by presence/absence of the P suffix.

JW

[EDIT] ...maybe LQFP48, too, although the DS does not mention it... [/edit]

[EDIT2] https://community.st.com/s/question/0D53W00000WZ2CjSAL/stm32l412cbt6-vs-stm32l412cbt6p-what-is-the-difference

[RRice.1]

Thanks for the quick answer. Same exact package. Still no clue why it programs and verifies and then seems unresponsive. So just to be clear a working binary on the 128 chip should just program and work on the 64 chip without and porting. Correct?

[waclawek.jan]

> Same exact package.

Post photo of old and new.

JW

[waclawek.jan]

> a working binary on the 128 chip should just program and work on the 64 chip without and porting. Correct?

Unless there's any code on the >64kB and/or any check of the size, most probably yes.

JW

[Paul1]

There are things that may fill up memory, or be located near end of memory.

Are you short its FLASH and not RAM? Heap and stack can fill out RAM.

Suggestion:

• Make a fresh copy of your project, but for the smaller memory chip.
• You can use the small memory build on the larger chip, but the opposite is risky.
• The reason is the "big" IC has all the features of the "small", but the "small" doesn't have everything from the "big".

Personally I would take the time to create the project fresh, and create a doc file showing all the screen captures of settings customized, and excerpts of any modified generated code - this can be helpful reference in future.

Personally I have downgraded code from STM32L496 to STM32L476 due to covid shortages, and found this approach works reliably.

Trying to squish code meant for the larger IC on the smaller is an unsafe shortcut.

Take the time to make a proper "small memory footprint" project.

Paul

[Paul1]

Quick test: Copy the linker file from a project created for the smaller memory IC, that will ensure everything links in valid memory.

Careful to check also any:

• hardware coded FLASH or RAM addresses
• all IO available - check tables in datasheet comparing part number features. Could be less UARTs/ADCs/etc.

I still think my previous suggestion is safer, the linker file change is just a quick test, not a solution.

Paul