Program doesn't work anymore after ST-Link upgrade

[thelankanguy]

 I had a program tested and running on a NUCLEO-F072RB for some time. Later I custom built my own PCB (using a STM32F072RBT6) and flashed the exact same code onto it using a STLINK-V3SET and the program did not work. I had no idea on why the program did not work. Later I decided to compare the memory data of my NUCLEO board and my custom PCB and identified that the address values look different one another. 

Later I did a firmware upgrade on my NUCLEO board and re programmed the board just to solve this program data mismatch. The device memory values now looked identical to that of the values on my custom PCB now. 

Since I tested and verified the functionality of my code on the NUCLEO board which apparently didn't have the latest firmware ran well and now after the upgrade it does not work as expected. This is strange and I would like to hear your expert opinions on this.

The attached images were obtained using the CubeProgrammer. The memory value mismatch can be clearly seen.

Thank You

[Pavel A.]

Hi,

It is hard to explain the difference, unless you can state that you use exactly same binary (or hex) file on both boards, with exactly same tool: CubeProgrammer or J-Flash or or ST-LINK utility etc.. Not with CubeIDE, because it produces ELF file then converts it... We need a reliable tool that flashes in the reproducible way.  TL;DR CubeIDE can be made to flash binaries in a reproducible way too, but better use one of the above tools.

[Tesla DeLorean]

Generally this is why you make a binary, or hex, or production image, and put that on devices and test pieces, rather than programming via the IDE, which might build differently on different PC's or if the tools/libraries get updated all the time.

[thelankanguy]

Thank you for your reply @Pavel A. 
I was using CubeIDE all this time to upload the same code both to my PCB and the NUCLEO. 
Only difference was using a STLINK-V3SET to upload the code to my PCB. 
Indeed I should stick to use CubeProgrammer to flash my MCUs hereafter. 
In the case of providing OTA upgrades to the firmware in the future might be challenging I guess.  

[unsigned_char_array]

We use the STLINK-V3SET all the time in both STM32CubeIDE and STM32CubeProgrammer. We even have a custom flash loader for external flash. There is no reason why STM32CubeIDE shouldn't flash the elf file in the same way as STM32CubeProgrammer if configured the same way unless one of them contains a bug. A different programmer should not make a difference unless it has a bug. For production we use batch files for STM32CubeProgrammer that also enable read protection for the flash (be careful not to brick the flash though).
The first words of the binary are the vector table and if the program is written at the beginning of the flash those words should be at the beginning of the flash. It could be that you are building and flashing a different target (debug, release, RAM, etc.) compared to the elf file you are flashing with STM32CubeProgrammer.
You are only showing us the difference between two memories, but not what they should be. Which one is correct or are they both wrong?
Is flash verification enabled?
With long cables 4MHz doesn't always work. Try 1 or 2MHz if you get connection errors. Though it shouldn't make a difference if you don't get errors.
Please show us your settings, elf file and log with higher verbosity.
If you can't share your code or binaries, I'm sure the same problem would occur if you create a simple blinky project. If a freshly created project doesn't have the same problems, then there is your answer. Make the configuration the same and the problem is solved.

[Pavel A.]

> There is no reason why STM32CubeIDE shouldn't flash the elf file in the same way as STM32CubeProgrammer if configured the same way unless one of them contains a bug.

Agree. But why to take chances :)  Bugs, features.... they happen.