STM32F103 Strange Behavior

[bogdanaioane]

Hi All,
I am encountering a very strange behavior from the STM32F103C8T6 and its diving me up the wall.... PLEASE HELP!
I have a relatively large firmware (Flash 82%, RAM 32%) that i developed in the prototyping stage of a device I'm working on. Everything works on the prototype which includes an OLED screen, capacitive touch sensors, EEPROM functions, Serial coms with a GSM module and internal RT clock. I developed it using Platform IO and VSCode and uploaded successfully using both USB bootloader or STlink V2.
The issue i have is that if i upload the same code on a "production" version of the device, the upload seems to go through but the device does nothing although inspecting it with the stlink utility shows that the code has been uploaded. I ofcourse went through an extensive hardware deboug to confirm there are no issues with the hardware. As an example if i disconnect all IO channels from the new hardware and just leave the MCU with the buttons and the screen I can upload a simple test code that confirms this works correctly. but if i try my code "the one that works on the prototype", it doesn't.
I initially thought that it might be because the prototype has the usb bootloader which the new device does not (i am uploading using STlink on the new device) but the fact that i can upload simple code that works makes me think that this is not it (or am I wrong and there are things that are needed from the usb bootloader that would only show issue with more complex code?? maybe RT Clock function??)
One thing that i tried and got another strange outcome is that if i export a .bin or.hex file from the working prototype using ST-Link Utility, I erase the working prototype chip and re-upload the .hex file, the prototype stops working too. (at this point I have to upload it from VSCode again either via USB or ST-link). I am starting to think that there is something I am missing when uploading .bin files from the ST-Link Utility??
Any suggestion will be much appreciated.
Thank you

[fpiSTM]

Did you found the issue?
For me it seems like an issue with the boot config ? or the reset signal management?

[stevestrong]

I also observed strange STLink upload behavior during the CDC bootloader development.
At a certain point I could not upload the BIN file with STlink but I could upload it using Eclipse and starting the debug session, or with STMCUbe programmer.
And the fail uploads varied somehow dependent on the code size: if it was very close to 4k then it failed.
So I suggest you to use the Cube programmer instead of STLink utility.

[stas2z]

I can assume the OP issue can be caused by different vector table offset, for binary compiled for usb bootloader it will be 0x2000 or 0x5000 for old one, but binary which is compiled to use without bl should have zero vector table offset
so binary, which compiled and work with prototype will not work if it will be uploaded to production device via swd without bootloader installed

upd. in terms of platformio, when you choose "dfu" upload type for f103 it will automagically set vector table offset to 0x2000
same thing will happen in case of arduino ide and usb bootloader option choosen

[ag123]

do take note that having a bootloader may shift the vector tab address. e.g. there are macros like

VECT_TAB_OFFSET=0 - STM core i think

VECT_TAB_ADDR=0x8002000 - libmaple core (e.g. with boot loader), without it should be 0x8000000

which defines the start address of the vector tab. normally these should be quite safe with selection of the appropriate 'upload method' etc.
my guess is one way to check is to build and install the same binary at 0x8000000 on a pill board without the boot loader e.g. via st-link.
if it stall in the same way, it may have something to do with those install selections during build.

[stevestrong]

In my case the app was always compiled for upload with STLink (vector at 0x08000000), the same BIN worked when uploaded with Cube programmer, and it failed when uploaded with STLink. In the later case the FLASH was corrupted (empty), and the utility sw had a freeze.