STM32F030 cant be flashed with openOCD
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-25 12:44 PM - last edited on ‎2024-11-26 12:07 PM by mƎALLEm
I'm tring to work with a STM32F030F4. Unfortunately I didn't manage to flash the application on the controller.
- I'm using openOCD with a ST-Link.
- I use the following to start openOCD: openocd.exe -f interface\stlink-v2.cfg -f target\stm32f0x.cfg
- I now use Telnet to talk to openOCD.
I do the following sequence:
Open On-Chip Debugger
> halt
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0xc1000003 pc: 0xfffffffe msp: 0xffffffd8
> mdw 0x08000000 30
0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x08000040: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x08000060: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
> flash fillw 0x08000000 0xAA55AA55 4
device id = 0x10006444
flash size = 16kbytes
Verification error address 0x08000000, read back 0xffffffff, expected 0xaa55aa55
> mdw 0x08000000 30
0x08000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x08000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x08000040: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x08000060: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
It seems that everything is fine as the communication with the chip works fine. Never the less I can't flash my application on the chip.
What could be the reason for that?
Could there be something missing on the hardware?
I'm using a selfmade board with:
- VDD and VDDA connected directly.
- Rst connected to a RC with 10k and 100nF
- Boot is connected directly to GND
- No external cristal
This are the Optionregister: 0x1ffff800: 00ff55aa 00ff00ff 00ff00ff 00ff00ff ffffffff ffffffff ffffffff ffffffff
This is the factory setting!
Thanks,
Drewle
- Labels:
-
STM32F0 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-25 5:01 PM
Which OpenOCD? ST has their own build of OpenOCD, shipped with CubeIDE (part of its debugger). Have you tried that?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-26 9:03 AM
Thank you for the quick response.
I used openOCD in the the version: OpenOCD-20201228-0.10.0. This is used to be an official version from the openOCD homepage.
Will it only work with the ST version of openOCD? What are the differences?
I have a STM32CubeIDE installed and also found openOCD in one of the subfolders. Unfortunately I didn't find a stlink-v2.cfg I used stlink.cfg. When I call this version of openOCD I get some stramge errors. Maybe there are some environment settings missing.
Could you please tell me how I must call openOCE from the STM32CubeIDE to access my STM32F030 with my ST-Link?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-26 10:31 AM - edited ‎2024-11-26 10:32 AM
> Will it only work with the ST version of openOCD? What are the differences?
The difference is simple: you use the ST version on STM32 and it works (if not - you can ask for support here). You run other version and waste time (and no support).
> how I must call openOCD from the STM32CubeIDE
Create any CubeIDE project for your MCU or board. Even take any example from the ST "Cube" firmware package. Then debug it: create a new debug configuration and select OpenOCD as debugger engine. CubeIDE will create all needed configuration files. You then can copy them or edit manually if needed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-26 11:40 AM
Ok. I tried with CubeIDE. The result is the same as with my setup:
Info : accepting 'gdb' connection on tcp/3333
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0xc1000003 pc: 0xfffffffe msp: 0xfffffffc
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : device id = 0x10006444
Info : flash size = 16kbytes
Error: Failed to read memory at 0xfffffffe
Error: Failed to read memory at 0xfffffffe
Info : accepting 'gdb' connection on tcp/3333
Error: Failed to read memory at 0xfffffffe
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0xc1000003 pc: 0xfffffffe msp: 0xfffffffc
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Error: stm32x device protected
Error: failed erasing sectors 0 to 3
Error: flash_erase returned -4
Info : dropped 'gdb' connection
shutdown command invoked
Info : dropped 'gdb' connection
I also have a demoboard with a STM32 F030C8T6 which works without problem.
The board we are talking about is a selve made PCB with a STM 32F030F4P6. (To make sure: I bougt the chip from reichelt electronic in germany. I'm quite shure it is anoriginal ST-product!)
- Is it possible that there is something missing on my board, which lead to a behavior like this?
- Is if possible that there are some differences between the C8T6 and the F4P6 regarding the execution of the debugger?
- Or is the most likely reason, that I crashed the controller when soldering?
(This would be strage, as everything but erasing seems to work fine.)
Thanks for your help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-26 2:14 PM - edited ‎2024-11-26 2:17 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-28 10:49 AM
I read the option registers:
This are the Optionregister: 0x1ffff800: 00ff55aa 00ff00ff 00ff00ff 00ff00ff ffffffff ffffffff ffffffff ffffffff
That is:
- USER = 0xFF
- RAM parity check disabled,
- VDDA power supply supervisor enabled,
- Boot1 = 1,
- Standby: No reset generated,
- Stop: No reset generated,
- Software watchdog)
- RDP = 0xAA (level 0)
- Data0..1 = 0xFF
- WRP0..3 = 0xFF (No writeprotect.)
This seams to be ok.
Maybe someone can help me and give me some helpful leads!
