2024-12-17 01:55 AM - last edited on 2024-12-17 01:47 PM by Tesla DeLorean
Hi all,
I have the CPU STM32F103 on board. I am using STM32CubeIDE for SW development and STM32CubeProgrammer for burning.
On some point during development, I couldn't burn the CPU anymore - I get various types of error messages, like 'Can't erase the memory', 'Core is halted' or the green bar (which indicates burning process) runs goes and back endlessly.
Yet sometimes I succeeded to bun it by using tricks, such setting port BOOT0 to VCC and using option OB --> Readout Protection to erase the memory and only then to program. Or alternatively pressing the on-board reset button and starting the programming immediately after releasing the button.
Unfortunately these trick are not always working, and off course are not acceptable as solution.
I wonder what happened to my design. Is there any solution?
Any help will be very appreciated.
2024-12-17 02:19 AM
Welcome to the forum.
@Shony wrote:I have the CPU STM32F103 on board.
What board?
How to write your question to maximize your chances to find a solution
2024-12-17 02:27 AM
My own design board.
2024-12-17 02:46 AM - edited 2024-12-17 02:53 AM
Then, as noted in the Posting Tips, please provide the schematic.
Also tool versions, what programming hardware you're using, etc
2024-12-17 03:41 AM
Not enough information for any reasoning.
The first guess: make sure that PA13 and PA14 pins are configured as SWD.
2024-12-17 07:28 AM
2024-12-17 07:33 AM
2024-12-17 08:02 AM
Schematics seems OK , SWD dont require pull ups, and STlink V2 preffered mode is SWD not JTAG.
Primary question : your loaded code use set MCU into low power STOP or STANDBY? When yes pregrammer cant connect it without use reset line and mode under reset... Same situation is if pins SWD is activated in code to other func.
2024-12-17 11:49 AM
Hi MM..1,
I don't use STOP or STANDBY.
Regarding the SW signals - I checked them on scope and found them OK. I need to check if I am mistakenly activating them to other function, but I wonder if they could work at-all in such case even after reset?
2024-12-17 01:40 PM
There's a window for things to work, If you connect the NRST to the Debugger it can make "Connect Under Reset" viable.
Similarly with BOOT0 and BOOT1 pins on the F1 it's possible to have it run the Loader out of System Memory, so your broken code won't interfere with PA13/PA14
If you disable the SWD/JTAG or reassign the pin usage, it makes it more difficult to connect.
Review your code/project.
We only know what you choose to share..