Menu
▾
▴
openocd-user — User support list for OpenOCD
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(26) |
Jun
(31) |
Jul
(16) |
Aug
(22) |
Sep
(26) |
Oct
(21) |
Nov
(7) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(29) |
Feb
(47) |
Mar
(27) |
Apr
(37) |
May
(17) |
Jun
(14) |
Jul
(8) |
Aug
(6) |
Sep
(26) |
Oct
(36) |
Nov
(6) |
Dec
(1) |
| 2014 |
Jan
(31) |
Feb
(11) |
Mar
(26) |
Apr
(28) |
May
(48) |
Jun
(38) |
Jul
(29) |
Aug
(17) |
Sep
(13) |
Oct
(36) |
Nov
(38) |
Dec
(15) |
| 2015 |
Jan
(14) |
Feb
(50) |
Mar
(9) |
Apr
(72) |
May
(34) |
Jun
(14) |
Jul
(12) |
Aug
(6) |
Sep
(44) |
Oct
(24) |
Nov
(11) |
Dec
(39) |
| 2016 |
Jan
(37) |
Feb
(10) |
Mar
(10) |
Apr
(5) |
May
(12) |
Jun
(3) |
Jul
(22) |
Aug
(42) |
Sep
(21) |
Oct
(11) |
Nov
(13) |
Dec
(5) |
| 2017 |
Jan
(34) |
Feb
(16) |
Mar
(13) |
Apr
(28) |
May
(8) |
Jun
(29) |
Jul
(17) |
Aug
(7) |
Sep
(6) |
Oct
(13) |
Nov
(5) |
Dec
(8) |
| 2018 |
Jan
(7) |
Feb
(27) |
Mar
(16) |
Apr
(4) |
May
|
Jun
(7) |
Jul
(16) |
Aug
(6) |
Sep
|
Oct
(18) |
Nov
(24) |
Dec
(7) |
| 2019 |
Jan
(22) |
Feb
(19) |
Mar
(12) |
Apr
(23) |
May
(15) |
Jun
(14) |
Jul
(27) |
Aug
(22) |
Sep
(8) |
Oct
(11) |
Nov
(26) |
Dec
(25) |
| 2020 |
Jan
(13) |
Feb
(11) |
Mar
(19) |
Apr
(29) |
May
(40) |
Jun
(15) |
Jul
(8) |
Aug
(13) |
Sep
(32) |
Oct
(41) |
Nov
(14) |
Dec
(16) |
| 2021 |
Jan
(2) |
Feb
(31) |
Mar
(18) |
Apr
(15) |
May
(24) |
Jun
(14) |
Jul
(39) |
Aug
(3) |
Sep
(10) |
Oct
(5) |
Nov
(18) |
Dec
(6) |
| 2022 |
Jan
(7) |
Feb
(12) |
Mar
(29) |
Apr
(9) |
May
|
Jun
(18) |
Jul
(19) |
Aug
(36) |
Sep
(9) |
Oct
|
Nov
(3) |
Dec
(25) |
| 2023 |
Jan
(62) |
Feb
(6) |
Mar
(35) |
Apr
(3) |
May
(9) |
Jun
(5) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
(6) |
Nov
(3) |
Dec
(7) |
| 2024 |
Jan
(16) |
Feb
(12) |
Mar
(26) |
Apr
(20) |
May
(6) |
Jun
(5) |
Jul
(6) |
Aug
(3) |
Sep
|
Oct
(1) |
Nov
|
Dec
(4) |
| 2025 |
Jan
(5) |
Feb
(3) |
Mar
(6) |
Apr
(1) |
May
|
Jun
(10) |
Jul
(6) |
Aug
|
Sep
(14) |
Oct
(2) |
Nov
|
Dec
|
|
From: Liviu I. <il...@li...> - 2025-10-05 05:40:02
|
https://xpack-dev-tools.github.io/openocd-xpack/blog/2025/10/05/openocd-v0-12-0-7-released/ |
|
From: Liviu I. <il...@li...> - 2025-10-03 10:30:35
|
With a little help from my friends (as the saying goes), I managed to find a functional configuration to run semihosted tests on the Pico:
```
add_test(
NAME "rtos-apis-test"
COMMAND ${pico_openocd}${extension}
# -d3
-c "gdb port disabled"
-c "tcl port disabled"
-c "telnet port disabled"
-f interface/cmsis-dap.cfg
-f target/rp2040.cfg
-c "adapter speed 5000"
-c "program rtos-apis-test.elf verify"
-c "arm semihosting enable"
-c "arm semihosting_cmdline rtos-apis-test"
-c "reset halt"
-c "rp2040.core0 arp_reset assert 0"
)
```
The `reset halt` asserts the reset on both cores, and the `arp_reset` releases the reset for core 0.
The application then runs until the semihosting SYS_EXIT is executed; openocd returns the test result.
I used the upstream openocd build several months ago, so it looks like there is no need for the raspberry fork of openocd.
Regards,
Liviu
|
|
From: Liviu I. <il...@li...> - 2025-09-30 10:23:47
|
Hi,
I have a test application that I build on various boards and run via openocd.
When I try to run it on the Pico, things are fine up to the moment when I try to run the application:
```
test 1
Start 1: rtos-apis-test
1: Test command: /Users/ilg/MyProjects/micro-os-plus.github/micro-os-plus-iii/micro-os-plus-iii.git/tests/build/raspberrypi-pico-cmake-debug/xpacks/.bin/openocd "-c" "gdb port disabled" "-c" "tcl port disabled" "-c" "telnet port disabled" "-f" "interface/cmsis-dap.cfg" "-f" "target/rp2040.cfg" "-c" "adapter speed 5000" "-c" "program rtos-apis-test.elf verify" "-c" "arm semihosting enable" "-c" "arm semihosting_cmdline rtos-apis-test" "-c" "reset run"
1: Working Directory: /Users/ilg/MyProjects/micro-os-plus.github/micro-os-plus-iii/micro-os-plus-iii.git/tests/build/raspberrypi-pico-cmake-debug/platform-bin
1: Test timeout computed to be: 10000000
1: xPack Open On-Chip Debugger 0.12.0+dev-01850-geb6f2745b-dirty (2025-02-07-12:14)
1: Licensed under GNU GPL v2
1: For bug reports, read
1: http://openocd.org/doc/doxygen/bugs.html
1: Info : Hardware thread awareness created
1: Info : Hardware thread awareness created
1: adapter speed: 5000 kHz
1: Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6616407E339502C
1: Info : CMSIS-DAP: SWD supported
1: Info : CMSIS-DAP: Atomic commands supported
1: Info : CMSIS-DAP: Test domain timer supported
1: Info : CMSIS-DAP: FW Version = 2.0.0
1: Info : CMSIS-DAP: Interface Initialised (SWD)
1: Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0
1: Info : CMSIS-DAP: Interface ready
1: Info : clock speed 5000 kHz
1: Info : SWD DPIDR 0x0bc12477, DLPIDR 0x00000001
1: Info : SWD DPIDR 0x0bc12477, DLPIDR 0x10000001
1: Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
1: Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
1: Info : [rp2040.core0] Examination succeed
1: Info : [rp2040.core1] Cortex-M0+ r0p1 processor detected
1: Info : [rp2040.core1] target has 4 breakpoints, 2 watchpoints
1: Info : [rp2040.core1] Examination succeed
1: Info : [rp2040.core0] gdb port disabled
1: Info : [rp2040.core1] gdb port disabled
1: [rp2040.core0] halted due to breakpoint, current mode: Thread
1: xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
1: [rp2040.core1] halted due to breakpoint, current mode: Thread
1: xPSR: 0xf1000000 pc: 0x000000ee msp: 0x20041f00
1: ** Programming Started **
1: Info : Found flash device 'win w25q16jv' (ID 0x001540ef)
1: Info : RP2040 B0 Flash Probe: 2097152 bytes @0x10000000, in 32 sectors
1:
1: Info : Padding image section 1 at 0x10058934 with 204 bytes (bank write end alignment)
1: Warn : Adding extra erase range, 0x10058a00 .. 0x1005ffff
1: ** Programming Finished **
1: ** Verify Started **
1: ** Verified OK **
1: semihosting is enabled
1: semihosting command line is [rtos-apis-test]
1: Error: [rp2040.core1] not halted
1: Warn : [rp2040.core0] resume of a SMP target failed, trying to resume current one
1: Error: [rp2040.core0] resume failed
1: Error: Failed to resume target
1: Error: [rp2040.core0] Polling failed, trying to reexamine
1: Info : [rp2040.core0] Cortex-M0+ r0p1 processor detected
1: Info : [rp2040.core0] target has 4 breakpoints, 2 watchpoints
1: Info : [rp2040.core0] Examination succeed
1: [rp2040.core0] halted due to debug-request, current mode: Thread
1: xPSR: 0x01000000 pc: 0x10018416 msp: 0x20041f68, semihosting
1: [rp2040.core1] halted due to debug-request, current mode: Thread
1: xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
1: Info : tcl server disabled
1: Info : telnet server disabled
```
openocd hangs at this point, and I have to kill it.
Running the same with -d3, I get (only the final part):
```
...
1: Debug: 1444 4923 command.c:153 script_debug(): command - arm semihosting enable
1: User : 1445 4923 options.c:52 configuration_output_handler(): semihosting is enabledUser : 1446 4923 options.c:52 configuration_output_handler():
1: Debug: 1447 4923 command.c:153 script_debug(): command - arm semihosting_cmdline rtos-apis-test
1: User : 1448 4923 options.c:52 configuration_output_handler(): semihosting command line is [rtos-apis-test]User : 1449 4923 options.c:52 configuration_output_handler():
1: Debug: 1450 4923 command.c:153 script_debug(): command - reset run
1: Debug: 1451 4923 target.c:1794 target_call_reset_callbacks(): target reset 1 (run)
1: Debug: 1452 4923 target.c:1794 target_call_reset_callbacks(): target reset 1 (run)
1: Debug: 1453 4923 command.c:153 script_debug(): command - target names
1: Debug: 1454 4923 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-start
1: Debug: 1455 4923 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-start
1: Debug: 1456 4923 command.c:153 script_debug(): command - transport select
1: Debug: 1457 4923 command.c:153 script_debug(): command - transport select
1: Debug: 1458 4923 command.c:153 script_debug(): command - rp2040.core0 invoke-event examine-start
1: Debug: 1459 4923 command.c:153 script_debug(): command - rp2040.core0 arp_examine allow-defer
1: Debug: 1460 4924 arm_adi_v5.c:935 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
1: Debug: 1461 4924 command.c:153 script_debug(): command - rp2040.core0 invoke-event examine-end
1: Debug: 1462 4924 command.c:153 script_debug(): command - transport select
1: Debug: 1463 4924 command.c:153 script_debug(): command - rp2040.core1 invoke-event examine-start
1: Debug: 1464 4924 command.c:153 script_debug(): command - rp2040.core1 arp_examine allow-defer
1: Debug: 1465 4925 arm_adi_v5.c:935 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
1: Debug: 1466 4925 command.c:153 script_debug(): command - rp2040.core1 invoke-event examine-end
1: Debug: 1467 4925 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-assert-pre
1: Debug: 1468 4925 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-assert-pre
1: Debug: 1469 4925 command.c:153 script_debug(): command - transport select
1: Debug: 1470 4925 command.c:153 script_debug(): command - rp2040.core0 arp_reset assert 0
1: Debug: 1471 4925 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1472 4925 target.c:1902 print_wa_layout(): 0x20010000-0x2001ffff (65536 bytes)
1: Debug: 1473 4925 cortex_m.c:1692 cortex_m_assert_reset(): [rp2040.core0] target->state: halted, examined
1: Debug: 1474 4927 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core0] NVIC_DFSR 0x1
1: Debug: 1475 4927 cortex_m.c:1806 cortex_m_assert_reset(): [rp2040.core0] Using Cortex-M SYSRESETREQ
1: Debug: 1476 4928 arm_adi_v5.c:859 dap_dp_init_or_reconnect(): rp2040.dap0
1: Debug: 1477 4928 arm_adi_v5.c:783 dap_dp_init(): rp2040.dap0
1: Debug: 1478 4928 arm_adi_v5.c:816 dap_dp_init(): DAP: wait CDBGPWRUPACK
1: Debug: 1479 4928 arm_adi_v5.h:683 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
1: Debug: 1480 4928 arm_adi_v5.c:824 dap_dp_init(): DAP: wait CSYSPWRUPACK
1: Debug: 1481 4928 arm_adi_v5.h:683 dap_dp_poll_register(): DAP: poll 4, mask 0x80000000, value 0x80000000
1: Debug: 1482 4928 cmsis_dap.c:839 cmsis_dap_swd_write_from_queue(): refusing to enable sticky overrun detection
1: Debug: 1483 4988 command.c:153 script_debug(): command - transport select
1: Debug: 1484 4988 command.c:153 script_debug(): command - rp2040.core1 arp_reset assert 0
1: Debug: 1485 4988 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1486 4988 cortex_m.c:1692 cortex_m_assert_reset(): [rp2040.core1] target->state: halted, examined
1: Debug: 1487 4990 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core1] NVIC_DFSR 0x1
1: Debug: 1488 4990 cortex_m.c:1806 cortex_m_assert_reset(): [rp2040.core1] Using Cortex-M SYSRESETREQ
1: Debug: 1489 4990 arm_adi_v5.c:859 dap_dp_init_or_reconnect(): rp2040.dap1
1: Debug: 1490 4991 arm_adi_v5.c:783 dap_dp_init(): rp2040.dap1
1: Debug: 1491 4991 arm_adi_v5.c:816 dap_dp_init(): DAP: wait CDBGPWRUPACK
1: Debug: 1492 4991 arm_adi_v5.h:683 dap_dp_poll_register(): DAP: poll 4, mask 0x20000000, value 0x20000000
1: Debug: 1493 4991 arm_adi_v5.c:824 dap_dp_init(): DAP: wait CSYSPWRUPACK
1: Debug: 1494 4991 arm_adi_v5.h:683 dap_dp_poll_register(): DAP: poll 4, mask 0x80000000, value 0x80000000
1: Debug: 1495 4991 cmsis_dap.c:839 cmsis_dap_swd_write_from_queue(): refusing to enable sticky overrun detection
1: Debug: 1496 5048 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-assert-post
1: Debug: 1497 5048 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-assert-post
1: Debug: 1498 5048 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-deassert-pre
1: Debug: 1499 5048 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-deassert-pre
1: Debug: 1500 5048 command.c:153 script_debug(): command - transport select
1: Debug: 1501 5048 command.c:153 script_debug(): command - rp2040.core0 arp_reset deassert 0
1: Debug: 1502 5048 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1503 5048 target.c:1902 print_wa_layout(): 0x20010000-0x2001ffff (65536 bytes)
1: Debug: 1504 5048 cortex_m.c:1850 cortex_m_deassert_reset(): [rp2040.core0] target->state: reset, examined
1: Debug: 1505 5049 command.c:153 script_debug(): command - transport select
1: Debug: 1506 5049 command.c:153 script_debug(): command - rp2040.core1 arp_reset deassert 0
1: Debug: 1507 5049 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1508 5049 cortex_m.c:1850 cortex_m_deassert_reset(): [rp2040.core1] target->state: reset, examined
1: Debug: 1509 5049 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-deassert-post
1: Debug: 1510 5049 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-deassert-post
1: Debug: 1511 5049 command.c:153 script_debug(): command - rp2040.core0 invoke-event reset-end
1: Debug: 1512 5049 command.c:153 script_debug(): command - rp2040.core1 invoke-event reset-end
1: Debug: 1513 5050 cortex_m.c:1013 cortex_m_poll_one(): [rp2040.core0] Exit from reset with dcb_dhcsr 0x30003
1: Debug: 1514 5050 cortex_m.c:619 cortex_m_endreset_event(): [rp2040.core0] DCB_DEMCR = 0x01000000
1: Debug: 1515 5051 target.c:2652 target_write_u32(): address: 0xe0002000, value: 0x00000003
1: Debug: 1516 5051 target.c:2564 target_read_u32(): address: 0xe0002000, value: 0x00000041
1: Debug: 1517 5051 target.c:2652 target_write_u32(): address: 0xe0002008, value: 0x00000000
1: Debug: 1518 5052 target.c:2652 target_write_u32(): address: 0xe000200c, value: 0x00000000
1: Debug: 1519 5052 target.c:2652 target_write_u32(): address: 0xe0002010, value: 0x00000000
1: Debug: 1520 5052 target.c:2652 target_write_u32(): address: 0xe0002014, value: 0x00000000
1: Debug: 1521 5052 target.c:2652 target_write_u32(): address: 0xe0001020, value: 0x00000000
1: Debug: 1522 5053 target.c:2652 target_write_u32(): address: 0xe0001024, value: 0x00000000
1: Debug: 1523 5053 target.c:2652 target_write_u32(): address: 0xe0001028, value: 0x00000000
1: Debug: 1524 5053 target.c:2652 target_write_u32(): address: 0xe0001030, value: 0x00000000
1: Debug: 1525 5053 target.c:2652 target_write_u32(): address: 0xe0001034, value: 0x00000000
1: Debug: 1526 5053 target.c:2652 target_write_u32(): address: 0xe0001038, value: 0x00000000
1: Debug: 1527 5054 cortex_m.c:852 cortex_m_debug_entry(): [rp2040.core0]
1: Debug: 1528 5055 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core0] NVIC_DFSR 0x3
1: Debug: 1529 5057 cortex_m.c:359 cortex_m_fast_read_all_regs(): [rp2040.core0] read 20 32-bit registers
1: Debug: 1530 5057 cortex_m.c:927 cortex_m_debug_entry(): [rp2040.core0] entered debug state in core mode: Thread at PC 0x100183d2, cpu in Non-Secure state, target->state: halted
1: Debug: 1531 5057 arm_adi_v5.c:401 mem_ap_setup_transfer_verify_size_packing(): AP#0x0 probed size 2: supported
1: Debug: 1532 5057 target.c:2588 target_read_u16(): address: 0x100183d2, value: 0xbeab
1: Debug: 1533 5057 semihosting_common.c:399 semihosting_common(): op=0x1 (OPEN), param=0x20041f70
1: Debug: 1534 5058 arm_adi_v5.c:401 mem_ap_setup_transfer_verify_size_packing(): AP#0x0 probed size 1: supported
1: Debug: 1535 5058 semihosting_common.c:977 semihosting_common(): dup(STDOUT)=5
1: Debug: 1536 5058 target.c:1776 target_call_event_callbacks(): target event 3 (resume-start) for core rp2040.core0
1: Debug: 1537 5058 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas
1: Debug: 1538 5058 target.c:1902 print_wa_layout(): 0x20010000-0x2001ffff (65536 bytes)
1: Debug: 1539 5058 target.c:2588 target_read_u16(): address: 0x100183d2, value: 0xbeab
1: Debug: 1540 5058 armv7m.c:1122 armv7m_maybe_skip_bkpt_inst(): [rp2040.core0] Skipping over BKPT instruction
1: Debug: 1541 5058 armv7m.c:199 armv7m_restore_context(): [rp2040.core0]
1: Debug: 1542 5059 armv7m.c:469 armv7m_write_core_reg(): [rp2040.core0] write pc value 0x100183d4
1: Debug: 1543 5059 armv7m.c:469 armv7m_write_core_reg(): [rp2040.core0] write r0 value 0x00000005
1: Error: 1544 5059 cortex_m.c:1323 cortex_m_restore_one(): [rp2040.core1] not halted
1: Warn : 1545 5059 cortex_m.c:1472 cortex_m_resume(): [rp2040.core0] resume of a SMP target failed, trying to resume current one
1: Debug: 1546 5059 target.c:1776 target_call_event_callbacks(): target event 2 (resumed) for core rp2040.core0
1: Error: 1547 5059 cortex_m.c:1477 cortex_m_resume(): [rp2040.core0] resume failed
1: Error: 1548 5059 arm_semihosting.c:63 arm_semihosting_resume(): Failed to resume target
1: Debug: 1549 5059 cortex_m.c:1056 cortex_m_poll_one(): [rp2040.core0] postpone target event 'halted'
1: Debug: 1550 5059 target.c:1776 target_call_event_callbacks(): target event 0 (gdb-halt) for core rp2040.core0
1: Error: 1551 5059 target.c:3000 handle_target(): [rp2040.core0] Polling failed, trying to reexamine
1: Debug: 1552 5059 target.c:674 target_examine_one(): [rp2040.core0] Examination started
1: Debug: 1553 5059 target.c:1776 target_call_event_callbacks(): target event 19 (examine-start) for core rp2040.core0
1: Debug: 1554 5059 arm_adi_v5.c:935 mem_ap_init(): MEM_AP CFG: large data 0, long address 0, big-endian 0
1: Debug: 1555 5060 target.c:2564 target_read_u32(): address: 0xe000ed00, value: 0x410cc601
1: Info : 1556 5060 cortex_m.c:2646 cortex_m_examine(): [rp2040.core0] Cortex-M0+ r0p1 processor detected
1: Debug: 1557 5060 cortex_m.c:2666 cortex_m_examine(): [rp2040.core0] cpuid: 0x410cc601
1: Debug: 1558 5060 target.c:2564 target_read_u32(): address: 0xe000edf0, value: 0x01030003
1: Debug: 1559 5060 target.c:2652 target_write_u32(): address: 0xe000edfc, value: 0x01000000
1: Debug: 1560 5060 target.c:2652 target_write_u32(): address: 0xe0000fb0, value: 0xc5acce55
1: Debug: 1561 5061 target.c:2564 target_read_u32(): address: 0xe0000e80, value: 0x00000000
1: Debug: 1562 5061 target.c:2652 target_write_u32(): address: 0xe0000e80, value: 0x00000000
1: Debug: 1563 5061 target.c:2564 target_read_u32(): address: 0xe0000e80, value: 0x00000000
1: Debug: 1564 5061 target.c:2652 target_write_u32(): address: 0xe0000e80, value: 0x00010009
1: Debug: 1565 5061 target.c:2652 target_write_u32(): address: 0xe0000e00, value: 0x00000001
1: Debug: 1566 5062 target.c:2652 target_write_u32(): address: 0xe0000e04, value: 0x00000000
1: Debug: 1567 5062 target.c:2652 target_write_u32(): address: 0xe0000e08, value: 0x00000000
1: Debug: 1568 5062 target.c:2652 target_write_u32(): address: 0xe0000e0c, value: 0x00000000
1: Debug: 1569 5062 target.c:2652 target_write_u32(): address: 0xe0000e10, value: 0x00000000
1: Debug: 1570 5062 target.c:2652 target_write_u32(): address: 0xe0000e14, value: 0x00000000
1: Debug: 1571 5063 target.c:2652 target_write_u32(): address: 0xe0000e18, value: 0x00000000
1: Debug: 1572 5063 target.c:2652 target_write_u32(): address: 0xe0000e1c, value: 0x00000000
1: Debug: 1573 5063 target.c:2564 target_read_u32(): address: 0xe0002000, value: 0x00000041
1: Debug: 1574 5063 target.c:2652 target_write_u32(): address: 0xe0002008, value: 0x00000000
1: Debug: 1575 5064 target.c:2652 target_write_u32(): address: 0xe000200c, value: 0x00000000
1: Debug: 1576 5064 target.c:2652 target_write_u32(): address: 0xe0002010, value: 0x00000000
1: Debug: 1577 5064 target.c:2652 target_write_u32(): address: 0xe0002014, value: 0x00000000
1: Debug: 1578 5064 cortex_m.c:2789 cortex_m_examine(): [rp2040.core0] FPB fpcr 0x41, numcode 4, numlit 0
1: Debug: 1579 5064 target.c:2564 target_read_u32(): address: 0xe0001000, value: 0x20000000
1: Debug: 1580 5064 cortex_m.c:2460 cortex_m_dwt_setup(): [rp2040.core0] DWT_CTRL: 0x20000000
1: Debug: 1581 5065 target.c:2564 target_read_u32(): address: 0xe0001fbc, value: 0x00000000
1: Debug: 1582 5065 cortex_m.c:2467 cortex_m_dwt_setup(): [rp2040.core0] DWT_DEVARCH: 0x0
1: Debug: 1583 5065 target.c:2652 target_write_u32(): address: 0xe0001028, value: 0x00000000
1: Debug: 1584 5065 target.c:2652 target_write_u32(): address: 0xe0001038, value: 0x00000000
1: Debug: 1585 5065 cortex_m.c:2516 cortex_m_dwt_setup(): [rp2040.core0] DWT dwtcr 0x20000000, comp 2, watch/trigger
1: Info : 1586 5065 cortex_m.c:2798 cortex_m_examine(): [rp2040.core0] target has 4 breakpoints, 2 watchpoints
1: Debug: 1587 5065 target.c:1776 target_call_event_callbacks(): target event 21 (examine-end) for core rp2040.core0
1: Info : 1588 5065 target.c:690 target_examine_one(): [rp2040.core0] Examination succeed
1: Debug: 1589 5066 cortex_m.c:1013 cortex_m_poll_one(): [rp2040.core1] Exit from reset with dcb_dhcsr 0x40001
1: Debug: 1590 5066 cortex_m.c:619 cortex_m_endreset_event(): [rp2040.core1] DCB_DEMCR = 0x01000000
1: Debug: 1591 5067 target.c:2652 target_write_u32(): address: 0xe0002000, value: 0x00000003
1: Debug: 1592 5067 target.c:2564 target_read_u32(): address: 0xe0002000, value: 0x00000041
1: Debug: 1593 5067 target.c:2652 target_write_u32(): address: 0xe0002008, value: 0x00000000
1: Debug: 1594 5067 target.c:2652 target_write_u32(): address: 0xe000200c, value: 0x00000000
1: Debug: 1595 5068 target.c:2652 target_write_u32(): address: 0xe0002010, value: 0x00000000
1: Debug: 1596 5068 target.c:2652 target_write_u32(): address: 0xe0002014, value: 0x00000000
1: Debug: 1597 5068 target.c:2652 target_write_u32(): address: 0xe0001020, value: 0x00000000
1: Debug: 1598 5068 target.c:2652 target_write_u32(): address: 0xe0001024, value: 0x00000000
1: Debug: 1599 5068 target.c:2652 target_write_u32(): address: 0xe0001028, value: 0x00000000
1: Debug: 1600 5069 target.c:2652 target_write_u32(): address: 0xe0001030, value: 0x00000000
1: Debug: 1601 5069 target.c:2652 target_write_u32(): address: 0xe0001034, value: 0x00000000
1: Debug: 1602 5069 target.c:2652 target_write_u32(): address: 0xe0001038, value: 0x00000000
1: Debug: 1603 5070 cortex_m.c:1202 cortex_m_halt_one(): [rp2040.core0] target->state: running
1: Debug: 1604 5071 cortex_m.c:1202 cortex_m_halt_one(): [rp2040.core1] target->state: running
1: Debug: 1605 5073 cortex_m.c:852 cortex_m_debug_entry(): [rp2040.core0]
1: Debug: 1606 5073 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core0] NVIC_DFSR 0x3
1: Debug: 1607 5076 cortex_m.c:359 cortex_m_fast_read_all_regs(): [rp2040.core0] read 20 32-bit registers
1: Debug: 1608 5076 cortex_m.c:927 cortex_m_debug_entry(): [rp2040.core0] entered debug state in core mode: Thread at PC 0x10018416, cpu in Non-Secure state, target->state: halted
1: Debug: 1609 5076 cortex_m.c:1056 cortex_m_poll_one(): [rp2040.core0] postpone target event 'halted'
1: Debug: 1610 5077 cortex_m.c:852 cortex_m_debug_entry(): [rp2040.core1]
1: Debug: 1611 5077 cortex_m.c:557 cortex_m_clear_halt(): [rp2040.core1] NVIC_DFSR 0x1
1: Debug: 1612 5080 cortex_m.c:359 cortex_m_fast_read_all_regs(): [rp2040.core1] read 20 32-bit registers
1: Debug: 1613 5080 cortex_m.c:927 cortex_m_debug_entry(): [rp2040.core1] entered debug state in core mode: Thread at PC 0x178, cpu in Non-Secure state, target->state: halted
1: Debug: 1614 5080 cortex_m.c:1056 cortex_m_poll_one(): [rp2040.core1] postpone target event 'halted'
1: Debug: 1615 5080 cortex_m.c:1171 cortex_m_poll_smp(): [rp2040.core0] sending postponed target event 'halted'
1: Debug: 1616 5080 target.c:1776 target_call_event_callbacks(): target event 0 (gdb-halt) for core rp2040.core0
1: Debug: 1617 5080 target.c:1776 target_call_event_callbacks(): target event 1 (halted) for core rp2040.core0
1: User : 1618 5080 armv7m.c:781 armv7m_arch_state(): [rp2040.core0] halted due to debug-request, current mode: Thread
1: xPSR: 0x01000000 pc: 0x10018416 msp: 0x20041f68, semihosting
1: Debug: 1619 5080 cortex_m.c:1171 cortex_m_poll_smp(): [rp2040.core1] sending postponed target event 'halted'
1: Debug: 1620 5080 target.c:1776 target_call_event_callbacks(): target event 0 (gdb-halt) for core rp2040.core1
1: Debug: 1621 5080 target.c:1776 target_call_event_callbacks(): target event 1 (halted) for core rp2040.core1
1: User : 1622 5080 armv7m.c:781 armv7m_arch_state(): [rp2040.core1] halted due to debug-request, current mode: Thread
1: xPSR: 0x01000000 pc: 0x00000178 msp: 0x20041f00
1: Info : 1623 5080 tcl_server.c:280 tcl_init(): tcl server disabled
1: Info : 1624 5080 telnet_server.c:945 telnet_init(): telnet server disabled
1: Debug: 1625 5080 command.c:153 script_debug(): command - init
```
The same ELF runs fine on the same board, when programmed with J-Link and Ozone
```
1.382 829 SEGGER Ozone - The J-Link Debugger V3.40b
1.605 091 J-Link software found at: /Applications/SEGGER/Ozone_V340b/Ozone.app/Contents/MacOS/Lib/libjlinkarm.dylib
8.423 831 File.NewProject();
31.200 443 File.Open: completed in 233 ms
31.200 755 Program segments:
31.200 777 Address Size Code RO Data RW Data ZI Data Flg
31.200 798 --------- --------- --------- --------- --------- --------- ---
31.200 806 10048148 0 0 0 0 0 R
31.200 814 10000000 295 164 275 952 19 212 0 0 RWE
31.200 822 20000000 54 716 0 0 54 716 0 RW
31.200 829 2000D5C0 13 560 0 0 0 13 560 RW
31.200 836 --------- --------- --------- --------- --------- --------- ---
31.200 842 Total: 363 440 275 952 19 212 54 716 13 560
31.200 847 --------- --------- --------- --------- --------- --------- ---
31.200 854 For further information on ELF file data sections, execute command Elf.PrintSectionInfo(0).
31.271 708 Debug.ReadIntoInstCache: updated instruction information within 2 code ranges (0x10000000-0x1004363C)
31.604 002 File.Open ("/Users/ilg/MyProjects/micro-os-plus.github/micro-os-plus-iii/micro-os-plus-iii.git/tests/build/raspberrypi-pico-cmake-debug/platform-bin/rtos-apis-test.elf");
36.182 476 Tools.DebugSettings();
01:16.697 191 J-Link settings were written to the project file.
01:16.713 477 Target core support plugin loaded.: /Applications/SEGGER/Ozone_V340b/Ozone.app/Contents/MacOS/Plugins/Core/CorePluginARM.dylib
01:16.751 314 Debug.ReadIntoInstCache: updated instruction information within 2 code ranges (0x10000000-0x1004363C)
01:16.969 723 Project.SetDevice ("RP2040_M0_0");
01:16.969 804 Project.SetTargetIF ("SWD");
01:16.970 091 Project.SetTIFSpeed ("4 MHz");
01:30.901 712 Debug.Start();
01:31.559 160 Device "RP2040_M0_0" selected.
01:31.595 029 ConfigTargetSettings() start
01:31.595 078 J-Link script: ConfigTargetSettings()
01:31.595 090 ConfigTargetSettings() end - Took 487us
01:31.595 098 Found SW-DP with ID 0x0BC12477
01:31.595 106 DPIDR: 0x0BC12477
01:31.595 112 CoreSight SoC-400 or earlier
01:31.595 121 Scanning AP map to find all available APs
01:31.595 129 AP[1]: Stopped AP scan as end of AP map has been reached
01:31.595 137 AP[0]: AHB-AP (IDR: 0x04770031, ADDR: 0x00000000)
01:31.595 146 Iterating through AP map to find AHB-AP to use
01:31.598 546 AP[0]: Core found
01:31.598 569 AP[0]: AHB-AP ROM base: 0xE00FF000
01:31.598 577 CPUID register: 0x410CC601. Implementer code: 0x41 (ARM)
01:31.598 584 Found Cortex-M0 r0p1, Little endian.
01:31.598 591 FPUnit: 4 code (BP) slots and 0 literal slots
01:31.598 597 CoreSight components:
01:31.598 604 ROMTbl[0] @ E00FF000
01:31.598 609 [0][0]: E000E000 CID B105E00D PID 000BB008 SCS
01:31.598 615 [0][1]: E0001000 CID B105E00D PID 000BB00A DWT
01:31.598 620 [0][2]: E0002000 CID B105E00D PID 000BB00B FPB
01:31.611 005 Connected to target device.
01:31.611 032 J-Link/J-Trace serial number: 174300531
01:31.655 079 Reset type: NORMAL (https://wiki.segger.com/J-Link_Reset_Strategies)
01:31.655 148 Reset: Halt core after reset via DEMCR.VC_CORERESET.
01:31.655 156 Reset: Reset device via AIRCR.SYSRESETREQ.
01:31.818 141 AfterResetTarget() start
01:31.818 174 AfterResetTarget() end - Took 2.81ms
01:32.718 737 J-Link: Flash download: Bank 0 @ 0x10000000: Skipped. Contents already match
01:32.726 600 Memory map 'after startup completion point' is active
01:32.813 757 Performing semihosting operation SysOpen.
01:32.814 884 Semihosting operation SysOpen completed with result code 4294967040.
01:32.853 144 Performing semihosting operation SysWrite.
01:32.854 220 Semihosting operation SysWrite completed with result code 0.
01:32.901 204 Performing semihosting operation SysWrite.
...
02:59.563 672 Semihosting operation SysWrite completed with result code 0.
02:59.611 834 Performing semihosting operation SysWrite.
02:59.612 876 Semihosting operation SysWrite completed with result code 0.
02:59.667 317 Performing semihosting operation SysWrite.
02:59.668 322 Semihosting operation SysWrite completed with result code 0.
02:59.716 675 Performing semihosting operation SysExit.
02:59.716 708 Target application exited with exit code (0x20026).
02:59.716 717 Semihosting operation SysExit completed with result code 131110.
02:59.716 774 Debug.Stop();
02:59.809 437 Disconnected from target device.
```
My experience with openocd is limited, and with multi-core devices even more limited, so I have difficulties to understand the debug log.
However I guess that the issue is somehow caused by the lack of specificity when reseting the target, probably it should mention explicitly that I want only the rp2040.core0 to run, and keep rp2040.core1 halted.
Any suggestions how to fix this?
Thank you,
Liviu
|
|
From: Christoph K. <ku...@ku...> - 2025-09-17 12:02:21
|
Thanks. My fault. > Am 17.09.2025 um 12:51 schrieb Paul Fertser <fer...@gm...>: > > On Wed, Sep 17, 2025 at 12:47:16PM +0200, Christoph Kukulies wrote: >> I'm not using the Nucleo F411 target. I wrote "Target is a WeAct Studio > > You are using nucleo F411 _target config_ though and that's why you're > seeing the error. > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fer...@gm... |
|
From: Christoph K. <ku...@ku...> - 2025-09-17 11:57:40
|
Sorry, I was a bit hasty. So, step by step: I added -c "arm semihosting enable" -c "arm semihosting_fileio enable" to the OpenOCD Command line options field in STM32CubeIDE Debugger launch panel: Show command line gives: /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin/openocd "-f" "SEMI Debug.cfg" "-s" "/Users/kuku/STM32CubeIDE/workspace_1.4.0/SEMI" "-s" "/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts" "-c" "arm semihosting enable" "-c" "arm semihosting_fileio enable" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444" Started and got the following error message: Open On-Chip Debugger 0.12.0+dev-00623-g0ba753ca7 (2025-04-30-14:20) [https://github.com/STMicroelectronics/OpenOCD <https://github.com/STMicroelectronics/OpenOCD>] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html <http://openocd.org/doc/doxygen/bugs.html> Error: The 'arm semihosting' command must be used after 'init'. So I thought, I'd add a -c "init" in front of that, which make the two options (arm semihosting enable and arm semihosting_fileio enable" obviously understood by OpenOCD since it writes them out: Open On-Chip Debugger 0.12.0+dev-00623-g0ba753ca7 (2025-04-30-14:20) [https://github.com/STMicroelectronics/OpenOCD <https://github.com/STMicroelectronics/OpenOCD>] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html <http://openocd.org/doc/doxygen/bugs.html> Info : STLINK V2J46M33 (API v2) VID:PID 0483:374B Info : Target voltage: 3.229804 Info : Unable to match requested speed 8000 kHz, using 4000 kHz Info : Unable to match requested speed 8000 kHz, using 4000 kHz Info : clock speed 4000 kHz Info : stlink_dap_op_connect(connect) Info : SWD DPIDR 0x6ba02477 Info : [STM32H503CBTx.ap0] Examination succeed Info : [STM32H503CBTx.cpu] Cortex-M33 r0p4 processor detected Info : [STM32H503CBTx.cpu] target has 8 breakpoints, 4 watchpoints STM32H503CBTx.cpu in Non-Secure state STM32H503CBTx TrustZone disabled STM32H503CBTx.cpu work-area address is set to 0x20000000 STM32H503CBTx.cpu work-area is enabled Info : [STM32H503CBTx.cpu] Examination succeed Info : gdb port disabled Info : starting gdb server for STM32H503CBTx.cpu on 3333 Info : Listening on port 3333 for gdb connections semihosting is enabled semihosting fileio is enabled Error: The 'gdb_report_data_abort' command must be used before 'init'. But then this last line? And as a control you can see the command line now: /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin/openocd "-f" "SEMI Debug.cfg" "-s" "/Users/kuku/STM32CubeIDE/workspace_1.4.0/SEMI" "-s" "/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts" "-c" "init" "-c" "arm semihosting enable" "-c" "arm semihosting_fileio enable" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444" > Am 16.09.2025 um 23:33 schrieb Tommy Murphy <tom...@ho...>: > > With applied, I'm told that these commands have occur after an "init" command. > So I added > > -c "init" in front of the above two flags. > > Result is this: > Error: The 'gdb_report_data_abort' command must be used before 'init'. > This is the complete command line of OpenOCD: > > /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin/openocd "-f" "SEMI Debug.cfg" "-s" "/Users/kuku/STM32CubeIDE/workspace_1.4.0/SEMI" "-s" "/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts" "-c" "arm semihosting enable" "-c" "arm semihosting_fileio enable" "-c" "gdb_report_data_abort enable" "-c" "gdb_port 3333" "-c" "tcl_port 6666" "-c" "telnet_port 4444" > > There's no -c "init" in that command line. |
|
From: Paul F. <fer...@gm...> - 2025-09-17 10:52:12
|
On Wed, Sep 17, 2025 at 12:47:16PM +0200, Christoph Kukulies wrote: > I'm not using the Nucleo F411 target. I wrote "Target is a WeAct Studio You are using nucleo F411 _target config_ though and that's why you're seeing the error. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: André v. S. <an...@bl...> - 2025-09-17 10:27:20
|
Your target is an STM32H5. You are loading a configuration for an STM32F4.
Op 17-09-2025 om 11:51 schreef Christoph Kukulies:
> I'm trying to connect to an STLINK/V2 unsing the following command:
>
> #!/bin/sh
>
> OPENOCD_BASE=/opt/local/var/macports/software/openocd/openocd-0.12.0_0+ftdi.darwin_20.x86_64/opt/local
> OPENOCD=${OPENOCD_BASE}/bin/openocd
>
> BOARD=${OPENOCD_BASE}/share/openocd/scripts/board/st_nucleo_f4.cfg
>
> ${OPENOCD} -f ${BOARD} -c "gdb_port 3333" -c "telnet_port 4444"
>
>
>
>
>
>
> Open On-Chip Debugger 0.12.0
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> Info : The selected transport took over low-level target control. The
> results might differ compared to plain JTAG/SWD
> srst_only separate srst_nogate srst_open_drain connect_deassert_srst
>
> Info : Listening on port 6666 for tcl connections
> Info : Listening on port 4444 for telnet connections
> Info : clock speed 2000 kHz
> Info : STLINK V2J46M33 (API v2) VID:PID 0483:374B
> Info : Target voltage: 3.226667
> Warn : UNEXPECTED idcode: 0x6ba02477
> Error: expected 1 of 1: 0x2ba01477
>
>
> What might be wrong? Target is a WeAct Studio STM32H503CBU6, macOS
> 11.7.10 (BigSur)
>
> --
> Christoph
>
>
>
> _______________________________________________
> OpenOCD-user mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-user
--
------------------------------------------------------------
an...@bl... http://www.blaatschaap.be
------------------------------------------------------------
|
|
From: Tommy M. <tom...@ho...> - 2025-09-17 10:13:38
|
Assuming that you're using the upstream/master OpenOCD sources here: https://openocd.org/pages/repos.html then this is your board script: https://github.com/openocd-org/openocd/blob/master/tcl/board/st_nucleo_f4.cfg which here: https://github.com/openocd-org/openocd/blob/0732a9bb7b3066ca10cd178986e9baea0f57f161/tcl/board/st_nucleo_f4.cfg#L13 references this target device script: https://github.com/openocd-org/openocd/blob/master/tcl/target/stm32f4x.cfg which here: https://github.com/openocd-org/openocd/blob/0732a9bb7b3066ca10cd178986e9baea0f57f161/tcl/target/stm32f4x.cfg#L36 expects this IDCODE (in SWD mode): 0x2ba01477 But your target is returning 0x6ba02477. There are a bunch of references elsewhere in the OpenOCD scripts to this IDCODE so maybe you're simply not using the appropriate scripts for your target? https://github.com/search?q=repo%3Aopenocd-org%2Fopenocd%20%200x6ba02477&type=code |
|
From: Christoph K. <ku...@ku...> - 2025-09-17 09:52:03
|
I'm trying to connect to an STLINK/V2 unsing the following command:
#!/bin/sh
OPENOCD_BASE=/opt/local/var/macports/software/openocd/openocd-0.12.0_0+ftdi.darwin_20.x86_64/opt/local
OPENOCD=${OPENOCD_BASE}/bin/openocd
BOARD=${OPENOCD_BASE}/share/openocd/scripts/board/st_nucleo_f4.cfg
${OPENOCD} -f ${BOARD} -c "gdb_port 3333" -c "telnet_port 4444"
Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 2000 kHz
Info : STLINK V2J46M33 (API v2) VID:PID 0483:374B
Info : Target voltage: 3.226667
Warn : UNEXPECTED idcode: 0x6ba02477
Error: expected 1 of 1: 0x2ba01477
What might be wrong? Target is a WeAct Studio STM32H503CBU6, macOS 11.7.10 (BigSur)
--
Christoph
|
|
From: Christoph K. <ku...@ku...> - 2025-09-13 09:54:00
|
I applied -d3. Here is the output: Open On-Chip Debugger 0.12.0+dev-00623-g0ba753ca7 (2025-04-30-14:20) [https://github.com/STMicroelectronics/OpenOCD] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html User : 3 13 options.c:52 configuration_output_handler(): debug_level: 3User : 4 13 options.c:52 configuration_output_handler(): Debug: 5 14 options.c:346 parse_cmdline_args(): ARGV[0] = "/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin/openocd" Debug: 6 14 options.c:346 parse_cmdline_args(): ARGV[1] = "-f" Debug: 7 14 options.c:346 parse_cmdline_args(): ARGV[2] = "SEMI Debug.cfg" Debug: 8 14 options.c:346 parse_cmdline_args(): ARGV[3] = "-s" Debug: 9 14 options.c:346 parse_cmdline_args(): ARGV[4] = "/Users/kuku/STM32CubeIDE/workspace_1.4.0/SEMI" Debug: 10 14 options.c:346 parse_cmdline_args(): ARGV[5] = "-s" Debug: 11 14 options.c:346 parse_cmdline_args(): ARGV[6] = "/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts" Debug: 12 14 options.c:346 parse_cmdline_args(): ARGV[7] = "-d3" Debug: 13 14 options.c:346 parse_cmdline_args(): ARGV[8] = "-c" Debug: 14 14 options.c:346 parse_cmdline_args(): ARGV[9] = "gdb_report_data_abort enable" Debug: 15 14 options.c:346 parse_cmdline_args(): ARGV[10] = "-c" Debug: 16 14 options.c:346 parse_cmdline_args(): ARGV[11] = "gdb_port 3333" Debug: 17 14 options.c:346 parse_cmdline_args(): ARGV[12] = "-c" Debug: 18 14 options.c:346 parse_cmdline_args(): ARGV[13] = "tcl_port 6666" Debug: 19 14 options.c:346 parse_cmdline_args(): ARGV[14] = "-c" Debug: 20 14 options.c:346 parse_cmdline_args(): ARGV[15] = "telnet_port 4444" Debug: 21 14 options.c:233 add_default_dirs(): bindir=/src/work/openocd/macos64/build/bin Debug: 22 14 options.c:234 add_default_dirs(): pkgdatadir=/src/work/openocd/macos64/build/share/openocd Debug: 23 14 options.c:235 add_default_dirs(): exepath=/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin Debug: 24 14 options.c:236 add_default_dirs(): bin2data=../share/openocd Debug: 25 14 configuration.c:33 add_script_search_dir(): adding /Users/kuku/Library/Preferences/org.openocd Debug: 26 14 configuration.c:33 add_script_search_dir(): adding /Users/kuku/.config/openocd Debug: 27 14 configuration.c:33 add_script_search_dir(): adding /Users/kuku/.openocd Debug: 28 14 configuration.c:33 add_script_search_dir(): adding /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin/../share/openocd/site Debug: 29 14 configuration.c:33 add_script_search_dir(): adding /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.openocd.macos64_2.4.200.202505051030/tools/bin/../share/openocd/scripts Debug: 30 14 command.c:153 script_debug(): command - ocd_find SEMI Debug.cfg Debug: 31 14 configuration.c:88 find_file(): found /Users/kuku/STM32CubeIDE/workspace_1.4.0/SEMI/SEMI Debug.cfg Debug: 32 14 command.c:153 script_debug(): command - ocd_find interface/stlink-dap.cfg Debug: 33 14 configuration.c:88 find_file(): found /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts/interface/stlink-dap.cfg Debug: 34 14 command.c:153 script_debug(): command - adapter driver st-link Debug: 35 15 command.c:153 script_debug(): command - st-link vid_pid 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 0x0483 0x3754 0x0483 0x3755 0x0483 0x3757 Debug: 36 15 command.c:153 script_debug(): command - transport select dapdirect_swd Debug: 37 15 adi_v5_dapdirect.c:187 dapdirect_swd_select(): dapdirect_swd_select() Debug: 38 16 command.c:153 script_debug(): command - reset_config srst_only srst_nogate connect_assert_srst Debug: 39 16 command.c:153 script_debug(): command - ocd_find target/stm32h5x.cfg Debug: 40 16 configuration.c:88 find_file(): found /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts/target/stm32h5x.cfg Debug: 41 16 command.c:153 script_debug(): command - ocd_find target/swj-dp.tcl Debug: 42 16 configuration.c:88 find_file(): found /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts/target/swj-dp.tcl Debug: 43 17 command.c:153 script_debug(): command - transport select Debug: 44 17 command.c:153 script_debug(): command - ocd_find mem_helper.tcl Debug: 45 17 configuration.c:88 find_file(): found /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts/mem_helper.tcl Debug: 46 17 command.c:153 script_debug(): command - add_usage_text mrw address Debug: 47 17 command.c:153 script_debug(): command - add_help_text mrw Returns value of word in memory. Debug: 48 17 command.c:153 script_debug(): command - add_usage_text mrh address Debug: 49 17 command.c:153 script_debug(): command - add_help_text mrh Returns value of halfword in memory. Debug: 50 17 command.c:153 script_debug(): command - add_usage_text mrb address Debug: 51 17 command.c:153 script_debug(): command - add_help_text mrb Returns value of byte in memory. Debug: 52 17 command.c:153 script_debug(): command - add_usage_text mmw address setbits clearbits Debug: 53 17 command.c:153 script_debug(): command - add_help_text mmw Modify word in memory. new_val = (old_val & ~clearbits) | setbits; Debug: 54 17 command.c:153 script_debug(): command - ocd_find gdb_helper.tcl Debug: 55 17 configuration.c:88 find_file(): found /Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.debug.openocd_2.3.100.202501240831/resources/openocd/st_scripts/gdb_helper.tcl Debug: 56 18 command.c:153 script_debug(): command - transport select Debug: 57 18 command.c:153 script_debug(): command - transport select Debug: 58 18 command.c:153 script_debug(): command - transport select Debug: 59 18 command.c:153 script_debug(): command - transport select Debug: 60 18 command.c:153 script_debug(): command - swd newdap STM32H503CBTx cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x0be12477 Debug: 61 18 tcl.c:402 handle_jtag_newtap_args(): Creating New Tap, Chip: STM32H503CBTx, Tap: cpu, Dotted: STM32H503CBTx.cpu, 8 params Debug: 62 18 core.c:1478 jtag_tap_init(): Created Tap: STM32H503CBTx.cpu @ abs position 0, irlen 4, capture: 0x1 mask: 0xf Debug: 63 18 command.c:153 script_debug(): command - dap create STM32H503CBTx.dap -chain-position STM32H503CBTx.cpu Debug: 64 18 command.c:153 script_debug(): command - target create STM32H503CBTx.ap0 mem_ap -endian little -dap STM32H503CBTx.dap -ap-num 0 Debug: 65 20 command.c:153 script_debug(): command - target create STM32H503CBTx.cpu cortex_m -endian little -dap STM32H503CBTx.dap -ap-num 1 -gdb-max-connections 2 Debug: 66 22 command.c:259 register_command(): command 'tpiu' is already registered Debug: 67 22 command.c:259 register_command(): command 'rtt' is already registered Debug: 68 22 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -work-area-phys 0x20000000 -work-area-size 0x8000 -work-area-backup 1 Debug: 69 22 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas Debug: 70 22 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas Debug: 71 22 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas Debug: 72 22 command.c:153 script_debug(): command - tpiu create STM32H503CBTx.tpiu -dap STM32H503CBTx.dap -ap-num 1 -baseaddr 0xE0040000 Debug: 73 22 command.c:153 script_debug(): command - flash bank STM32H503CBTx.flash_ns stm32h5x 0x08000000 0 0 0 STM32H503CBTx.cpu Debug: 74 24 tcl.c:1306 handle_flash_bank_command(): 'stm32h5x' driver usage field missing Debug: 75 24 command.c:153 script_debug(): command - flash bank STM32H503CBTx.flash_alias_s stm32h5x 0x0C000000 0 0 0 STM32H503CBTx.cpu Debug: 76 24 command.c:259 register_command(): command 'stm32h5x' is already registered Debug: 77 24 command.c:259 register_command(): command 'stm32h5x mass_erase' is already registered Debug: 78 24 command.c:259 register_command(): command 'stm32h5x option_read' is already registered Debug: 79 24 command.c:259 register_command(): command 'stm32h5x option_write' is already registered Debug: 80 24 command.c:259 register_command(): command 'stm32h5x trustzone' is already registered Debug: 81 24 command.c:259 register_command(): command 'stm32h5x option_load' is already registered Debug: 82 24 command.c:259 register_command(): command 'stm32h5x write_obk' is already registered Debug: 83 24 command.c:259 register_command(): command 'stm32h5x write_obk_options' is already registered Debug: 84 24 tcl.c:1306 handle_flash_bank_command(): 'stm32h5x' driver usage field missing Debug: 85 24 command.c:153 script_debug(): command - adapter speed 8000 Debug: 86 24 adapter.c:250 adapter_config_khz(): handle adapter khz Debug: 87 24 adapter.c:214 adapter_khz_to_speed(): convert khz to adapter specific speed value Debug: 88 24 adapter.c:214 adapter_khz_to_speed(): convert khz to adapter specific speed value Debug: 89 24 command.c:153 script_debug(): command - adapter srst delay 100 Debug: 90 25 command.c:153 script_debug(): command - transport select Debug: 91 25 command.c:153 script_debug(): command - transport select Debug: 92 25 command.c:153 script_debug(): command - cortex_m reset_config sysresetreq Debug: 93 25 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -event reset-init global _CLOCK_FREQ adapter speed $_CLOCK_FREQ Debug: 94 25 command.c:153 script_debug(): command - STM32H503CBTx.ap0 configure -event examine-end set _CHIPNAME [stm32h5x_get_chipname] # Enable Trace Port and Clock (uses more power) # DBGMCU_CR |= TRACE_EN stm32h5x_mmw $_CHIPNAME.ap0 0xE0044004 0x00000020 0 Debug: 95 25 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -event gdb-flash-erase-start set _CHIPNAME [stm32h5x_get_chipname] global $_CHIPNAME.tz $_CHIPNAME.pstate # halt if cpu not in OPEN product state if {1 == [set $_CHIPNAME.tz] && 0xED != [set $_CHIPNAME.pstate]} { halt } else { reset init } Debug: 96 25 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -event reset-start set _CHIPNAME [stm32h5x_get_chipname] global $_CHIPNAME.tz $_CHIPNAME.pstate global NS_Reset_Handler_address set initialized [expr {[info exists $_CHIPNAME.tz] && [info exists $_CHIPNAME.pstate]}] if {$initialized && 1 == [set $_CHIPNAME.tz] && 0xED != [set $_CHIPNAME.pstate]} { if {$halt} { halt # Don't get Non Secure Reset Handler address if it is entered in debug configuration if { ![info exists NS_Reset_Handler_address] } { set VTOR_S [mrw 0xe000ed08] set Reset_add [expr {($VTOR_S + 4)}] set NS_Reset_Handler_address [read_memory $Reset_add 32 1] } bp $NS_Reset_Handler_address 2 hw } } Debug: 97 25 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -event reset-end set _CHIPNAME [stm32h5x_get_chipname] global $_CHIPNAME.tz $_CHIPNAME.pstate global NS_Reset_Handler_address set initialized [expr {[info exists $_CHIPNAME.tz] && [info exists $_CHIPNAME.pstate]}] if {$initialized && 1 == [set $_CHIPNAME.tz] && 0xED != [set $_CHIPNAME.pstate]} { if {$halt} { if { ![info exists NS_Reset_Handler_address] } { set VTOR_S [mrw 0xe000ed08] set Reset_add [expr {($VTOR_S + 4)}] set NS_Reset_Handler_address [read_memory $Reset_add 32 1] } rbp $NS_Reset_Handler_address } } global FLASH_LOADERS global NAME_INITIALIZED_LOADER global INDEX_INITIALIZED_LOADER if { [info exists INDEX_INITIALIZED_LOADER] } { set NAME_INITIALIZED_LOADER [lindex $FLASH_LOADERS $INDEX_INITIALIZED_LOADER] set flash_list [flash list] for {set i 0} {$i < [llength $flash_list]} {incr i} { if { [lindex [lindex $flash_list $i] 1] == $NAME_INITIALIZED_LOADER } { set INIT_BANK_ID $i break } } if { ![info exists INIT_BANK_ID] } { echo "ERROR: can't find bank_id for stldr init" } else { stldr init $INIT_BANK_ID } } Debug: 98 25 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -event examine-end global _ENABLE_LOW_POWER global _STOP_WATCHDOG stm32h5x_enter_debug set _CHIPNAME [stm32h5x_get_chipname] if { $_ENABLE_LOW_POWER == 1 } { # Enable debug during low power modes (uses more power) # DBGMCU_CR |= DBG_STANDBY | DBG_STOP stm32h5x_mmw $_CHIPNAME.ap0 0xE0044004 0x00000006 0 } else { # Disable debug during low power modes # DBGMCU_CR |= ~(DBG_STANDBY | DBG_STOP) stm32h5x_mmw $_CHIPNAME.ap0 0xE0044004 0 0x00000006 } if { $_STOP_WATCHDOG == 1 } { # Stop watchdog counters during halt # DBGMCU_APB1_FZ |= DBG_IWDG_STOP | DBG_WWDG_STOP stm32h5x_mmw $_CHIPNAME.ap0 0xE0044008 0x00001800 0 } else { # Don't stop watchdog counters during halt # DBGMCU_APB1_FZ |= ~(DBG_IWDG_STOP | DBG_WWDG_STOP) stm32h5x_mmw $_CHIPNAME.ap0 0xE0044008 0 0x00001800 } Debug: 99 25 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -event halted stm32h5x_enter_debug Debug: 100 25 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -event gdb-attach gdb_attach_hook Debug: 101 25 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -event gdb-detach gdb_detach_hook Debug: 102 25 command.c:153 script_debug(): command - gdb_report_data_abort enable Debug: 103 25 command.c:153 script_debug(): command - gdb_port 3333 Debug: 104 25 command.c:153 script_debug(): command - tcl_port 6666 Debug: 105 25 command.c:153 script_debug(): command - telnet_port 4444 Info : 106 25 server.c:299 add_service(): Listening on port 6666 for tcl connections Info : 107 25 server.c:299 add_service(): Listening on port 4444 for telnet connections Debug: 108 25 command.c:153 script_debug(): command - init Debug: 109 25 command.c:153 script_debug(): command - target init Debug: 110 25 command.c:153 script_debug(): command - target names Debug: 111 25 command.c:153 script_debug(): command - STM32H503CBTx.ap0 cget -event gdb-flash-erase-start Debug: 112 26 command.c:153 script_debug(): command - STM32H503CBTx.ap0 configure -event gdb-flash-erase-start reset init Debug: 113 26 command.c:153 script_debug(): command - STM32H503CBTx.ap0 cget -event gdb-flash-write-end Debug: 114 26 command.c:153 script_debug(): command - STM32H503CBTx.ap0 configure -event gdb-flash-write-end reset halt Debug: 115 26 command.c:153 script_debug(): command - STM32H503CBTx.ap0 cget -event gdb-attach Debug: 116 26 command.c:153 script_debug(): command - STM32H503CBTx.ap0 configure -event gdb-attach halt 1000 Debug: 117 26 command.c:153 script_debug(): command - STM32H503CBTx.cpu cget -event gdb-flash-erase-start Debug: 118 26 command.c:153 script_debug(): command - STM32H503CBTx.cpu cget -event gdb-flash-write-end Debug: 119 26 command.c:153 script_debug(): command - STM32H503CBTx.cpu configure -event gdb-flash-write-end reset halt Debug: 120 26 command.c:153 script_debug(): command - STM32H503CBTx.cpu cget -event gdb-attach Debug: 121 26 target.c:1588 handle_target_init_command(): Initializing targets... Debug: 122 26 mem_ap.c:61 mem_ap_init_target(): mem_ap_init_target Debug: 123 26 semihosting_common.c:107 semihosting_common_init(): Debug: 124 26 stlink_usb.c:5155 stlink_dap_init(): stlink_dap_init() Debug: 125 26 stlink_usb.c:3735 stlink_open(): stlink_open Debug: 126 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3748 serial: Debug: 127 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374b serial: Debug: 128 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374d serial: Debug: 129 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374e serial: Debug: 130 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x374f serial: Debug: 131 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3752 serial: Debug: 132 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3753 serial: Debug: 133 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3754 serial: Debug: 134 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3755 serial: Debug: 135 26 stlink_usb.c:3749 stlink_open(): transport: 4 vid: 0x0483 pid: 0x3757 serial: Info : 136 51 stlink_usb.c:1475 stlink_usb_version(): STLINK V2J46S7 (API v2) VID:PID 0483:3748 Debug: 137 51 stlink_usb.c:1699 stlink_usb_exit_mode(): MODE: 0x01 Info : 138 52 stlink_usb.c:1507 stlink_usb_check_voltage(): Target voltage: 2.568143 Debug: 139 52 stlink_usb.c:1767 stlink_usb_init_mode(): MODE: 0x01 Debug: 140 52 stlink_usb.c:3133 stlink_dump_speed_map(): Supported clock speeds are: Debug: 141 52 stlink_usb.c:3136 stlink_dump_speed_map(): 4000 kHz Debug: 142 52 stlink_usb.c:3136 stlink_dump_speed_map(): 1800 kHz Debug: 143 52 stlink_usb.c:3136 stlink_dump_speed_map(): 1200 kHz Debug: 144 52 stlink_usb.c:3136 stlink_dump_speed_map(): 950 kHz Debug: 145 52 stlink_usb.c:3136 stlink_dump_speed_map(): 480 kHz Debug: 146 52 stlink_usb.c:3136 stlink_dump_speed_map(): 240 kHz Debug: 147 52 stlink_usb.c:3136 stlink_dump_speed_map(): 125 kHz Debug: 148 52 stlink_usb.c:3136 stlink_dump_speed_map(): 100 kHz Debug: 149 52 stlink_usb.c:3136 stlink_dump_speed_map(): 50 kHz Debug: 150 52 stlink_usb.c:3136 stlink_dump_speed_map(): 25 kHz Debug: 151 52 stlink_usb.c:3136 stlink_dump_speed_map(): 15 kHz Debug: 152 52 stlink_usb.c:3136 stlink_dump_speed_map(): 5 kHz Debug: 153 344 stlink_usb.c:1088 stlink_usb_error_check(): STLINK_JTAG_GET_IDCODE_ERROR Error: 154 344 stlink_usb.c:3790 stlink_open(): init mode failed (unable to connect to the target) Debug: 155 344 stlink_usb.c:1699 stlink_usb_exit_mode(): MODE: 0x01 Debug: 156 345 command.c:529 exec_command(): Command 'init' failed with error code -4 User : 157 345 command.c:601 command_run_line(): Debug: 158 346 breakpoints.c:328 breakpoint_remove_all_internal(): [STM32H503CBTx.ap0] Delete all breakpoints Debug: 159 346 mem_ap.c:71 mem_ap_deinit_target(): mem_ap_deinit_target Debug: 160 346 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas Debug: 161 346 breakpoints.c:328 breakpoint_remove_all_internal(): [STM32H503CBTx.cpu] Delete all breakpoints Debug: 162 346 target.c:2130 target_free_all_working_areas_restore(): freeing all working areas > Am 13.09.2025 um 11:06 schrieb Tommy Murphy <tom...@ho...>: > > > Could relatively low target voltgae (2.71 V) be a problem? > > Perhaps, but a verbose -d3 log might shed more light on the issue and should be the first step in investigating such an issue. |
|
From: André v. S. <an...@bl...> - 2025-09-13 09:28:22
|
That voltage does look a bit off. So unless your PCB is designed to run on that voltage, I'd recommend to check the power supply and the wiring to the debugger. André Op 13-09-2025 om 11:03 schreef Christoph Kukulies: > Thanks. Yes, STM32CubeIDE runs its own built-in OpenOCD. I'll ask my > question in the ST forum. > Could relatively low target voltgae (2.71 V) be a problem? > > -- > Christoph > >> Am 13.09.2025 um 01:00 schrieb Tommy Murphy <tom...@ho...>: >> >> Doesn't STM32CubeIDE use its own fork of OpenOCD rather than the >> version in the main OpenOCD project? >> >> https://github.com/STMicroelectronics/OpenOCD >> >> If so then issues should probably be reported there? >> >> Whatever version of OpenOCD is used, when you have connection issues >> or other issues such as this the first step is to capture a verbose >> openocd -d3 log that might shed more light on the root cause of the >> issue. >> >> ------------------------------------------------------------------------ >> *From:* Christoph Kukulies <ku...@ku...> >> *Sent:* Friday, September 12, 2025 3:25:40 PM >> *To:* ope...@li... >> <ope...@li...> >> *Subject:* [OpenOCD-user] Configuring builtin OpenOCD in STM32CubeIDE >> I'm trying to run a Debug launch configuration in STM32CubeIDE but >> I'm getting an error: >> >> Console: >> >> >> Open On-Chip Debugger 0.12.0+dev-00623-g0ba753ca7 (2025-04-30-14:20) >> [https://github.com/STMicroelectronics/OpenOCD] >> Licensed under GNU GPL v2 >> For bug reports, read >> http://openocd.org/doc/doxygen/bugs.html >> Info : Listening on port 6666 for tcl connections >> Info : Listening on port 4444 for telnet connections >> Info : STLINK V2J46S7 (API v2) VID:PID 0483:3748 >> Info : Target voltage: 2.716832 >> Error: init mode failed (unable to connect to the target) >> >> >> Error message of STM32 popping up: >> >> >> Error in final launch sequence: >> >> Failed to execute MI command: >> target extended-remote localhost:3333 >> >> Error message from debugger back end: >> localhost:3333: Operation timed out. >> Failed to execute MI command: >> target extended-remote localhost:3333 >> >> Error message from debugger back end: >> localhost:3333: Operation timed out. >> localhost:3333: Operation timed out. >> >> >> Any ideas what I'm doing wrong? >> >> -- >> Christoph >> > > > > _______________________________________________ > OpenOCD-user mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openocd-user |
|
From: Tommy M. <tom...@ho...> - 2025-09-13 09:06:37
|
> Could relatively low target voltgae (2.71 V) be a problem? Perhaps, but a verbose -d3 log might shed more light on the issue and should be the first step in investigating such an issue. |
|
From: Christoph K. <ku...@ku...> - 2025-09-13 09:04:09
|
Thanks. Yes, STM32CubeIDE runs its own built-in OpenOCD. I'll ask my question in the ST forum. Could relatively low target voltgae (2.71 V) be a problem? -- Christoph > Am 13.09.2025 um 01:00 schrieb Tommy Murphy <tom...@ho...>: > > Doesn't STM32CubeIDE use its own fork of OpenOCD rather than the version in the main OpenOCD project? > > https://github.com/STMicroelectronics/OpenOCD <https://github.com/STMicroelectronics/OpenOCD> > > If so then issues should probably be reported there? > > Whatever version of OpenOCD is used, when you have connection issues or other issues such as this the first step is to capture a verbose openocd -d3 log that might shed more light on the root cause of the issue. > > From: Christoph Kukulies <ku...@ku...> > Sent: Friday, September 12, 2025 3:25:40 PM > To: ope...@li... <ope...@li...> > Subject: [OpenOCD-user] Configuring builtin OpenOCD in STM32CubeIDE > > I'm trying to run a Debug launch configuration in STM32CubeIDE but I'm getting an error: > > Console: > > > Open On-Chip Debugger 0.12.0+dev-00623-g0ba753ca7 (2025-04-30-14:20) [https://github.com/STMicroelectronics/OpenOCD <https://github.com/STMicroelectronics/OpenOCD>] > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.org/doc/doxygen/bugs.html <http://openocd.org/doc/doxygen/bugs.html> > Info : Listening on port 6666 for tcl connections > Info : Listening on port 4444 for telnet connections > Info : STLINK V2J46S7 (API v2) VID:PID 0483:3748 > Info : Target voltage: 2.716832 > Error: init mode failed (unable to connect to the target) > > > Error message of STM32 popping up: > > > Error in final launch sequence: > > Failed to execute MI command: > target extended-remote localhost:3333 > > Error message from debugger back end: > localhost:3333: Operation timed out. > Failed to execute MI command: > target extended-remote localhost:3333 > > Error message from debugger back end: > localhost:3333: Operation timed out. > localhost:3333: Operation timed out. > > > Any ideas what I'm doing wrong? > > -- > Christoph > |
|
From: Tommy M. <tom...@ho...> - 2025-09-12 23:16:02
|
Doesn't STM32CubeIDE use its own fork of OpenOCD rather than the version in the main OpenOCD project? https://github.com/STMicroelectronics/OpenOCD If so then issues should probably be reported there? Whatever version of OpenOCD is used, when you have connection issues or other issues such as this the first step is to capture a verbose openocd -d3 log that might shed more light on the root cause of the issue. ________________________________ From: Christoph Kukulies <ku...@ku...> Sent: Friday, September 12, 2025 3:25:40 PM To: ope...@li... <ope...@li...> Subject: [OpenOCD-user] Configuring builtin OpenOCD in STM32CubeIDE I'm trying to run a Debug launch configuration in STM32CubeIDE but I'm getting an error: Console: Open On-Chip Debugger 0.12.0+dev-00623-g0ba753ca7 (2025-04-30-14:20) [https://github.com/STMicroelectronics/OpenOCD] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : STLINK V2J46S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 2.716832 Error: init mode failed (unable to connect to the target) Error message of STM32 popping up: Error in final launch sequence: Failed to execute MI command: target extended-remote localhost:3333 Error message from debugger back end: localhost:3333: Operation timed out. Failed to execute MI command: target extended-remote localhost:3333 Error message from debugger back end: localhost:3333: Operation timed out. localhost:3333: Operation timed out. Any ideas what I'm doing wrong? -- Christoph |
|
From: Christoph K. <ku...@ku...> - 2025-09-12 14:50:53
|
I'm trying to run a Debug launch configuration in STM32CubeIDE but I'm getting an error: Console: Open On-Chip Debugger 0.12.0+dev-00623-g0ba753ca7 (2025-04-30-14:20) [https://github.com/STMicroelectronics/OpenOCD] Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : STLINK V2J46S7 (API v2) VID:PID 0483:3748 Info : Target voltage: 2.716832 Error: init mode failed (unable to connect to the target) Error message of STM32 popping up: Error in final launch sequence: Failed to execute MI command: target extended-remote localhost:3333 Error message from debugger back end: localhost:3333: Operation timed out. Failed to execute MI command: target extended-remote localhost:3333 Error message from debugger back end: localhost:3333: Operation timed out. localhost:3333: Operation timed out. Any ideas what I'm doing wrong? -- Christoph |
|
From: Zixian Z. <syc...@gm...> - 2025-07-21 10:13:05
|
Hi Paul: On Fri, Jul 18, 2025 at 05:24:11PM +0000, Paul Rothhammer-Ruiz wrote: > Hello OpenOCD developers, > > I am using OpenOCD version 0.12.0 on a windows machine (openOCD is running on MSYS2). I have successfully used openOCD for years. Recently when using an STM32F334 (64KB flash size), I am occasionally getting errors when flashing. The error message is: "Error: error writing to flash at address 0x08000000 at offset 0x00000000." This error seems to be binary file dependent. Flashing will immediately work again on openOCD if I switch over to flashing a "known good" binary file. In fact, I can often get a problematic binary file to flash successfully if I delete random lines of code in the file. > I would think the issue is the size of the binary file, however, I am able to successfully flash the "bad" binary file using the STM32CubeProgrammer. I confirmed this by doing a simple LED blink program; it would not flash with OpenOCD but LEDs did blink once I tried with STM32CubeProgrammer. When using the size utility (arm-none-eabi-size) I get text=12652, data=120, bss=1696, dec=14468. I should have plenty of space left on the STM32F334. I am using default the default linker script generated by the STM32CubeProgrammer. > When I enable a verbose output on OpenOCD, I see the following error message: > "Error: 596 2811 core.c:96 flash_driver_write(): error writing to flash at address 0x08000000 at offset 0x00000000 > Debug: 597 2815 command.c:545 run_command(): Command 'flash write_image' failed with error code -4" > Please advise how I can best troubleshoot this issue. I rely on OpenOCD for flashing and debugging. > Thank you in advance! > > Regards, > Paul I have similar issue before when I was using the STM32H755ZI-Q with dual cores. The most possible reason I can guess is "You LOCKED your flash accidentally". If I remembered correctly, flash memory on STM32 might trap into a "broken state" when you did something "bad". According to STM32H755ZI-Q user guide, STM32CubeProgrammer can help to erase the broken flash sector. I have try it and after that I find a similar feature in OpenOCD, you can use "-c help" option and search keyword "flash" on your board. For your reference, I used the similar commands like following one: openocd -f interface/stlink.cfg -f target/stm32h7x_dual_bank.cfg -c init -c "flash erase_sector 0 0 last" I not a develop of OpenOCD, Sorry if I was misleading. Best regards, Zixian |
|
From: Paul Rothhammer-R. <Pau...@lu...> - 2025-07-18 17:24:29
|
Hello OpenOCD developers, I am using OpenOCD version 0.12.0 on a windows machine (openOCD is running on MSYS2). I have successfully used openOCD for years. Recently when using an STM32F334 (64KB flash size), I am occasionally getting errors when flashing. The error message is: "Error: error writing to flash at address 0x08000000 at offset 0x00000000." This error seems to be binary file dependent. Flashing will immediately work again on openOCD if I switch over to flashing a "known good" binary file. In fact, I can often get a problematic binary file to flash successfully if I delete random lines of code in the file. I would think the issue is the size of the binary file, however, I am able to successfully flash the "bad" binary file using the STM32CubeProgrammer. I confirmed this by doing a simple LED blink program; it would not flash with OpenOCD but LEDs did blink once I tried with STM32CubeProgrammer. When using the size utility (arm-none-eabi-size) I get text=12652, data=120, bss=1696, dec=14468. I should have plenty of space left on the STM32F334. I am using default the default linker script generated by the STM32CubeProgrammer. When I enable a verbose output on OpenOCD, I see the following error message: "Error: 596 2811 core.c:96 flash_driver_write(): error writing to flash at address 0x08000000 at offset 0x00000000 Debug: 597 2815 command.c:545 run_command(): Command 'flash write_image' failed with error code -4" Please advise how I can best troubleshoot this issue. I rely on OpenOCD for flashing and debugging. Thank you in advance! Regards, Paul This message and any attachments are Confidential Information, for the exclusive use of the addressee and may be legally privileged. Any receipt by anyone other than the intended addressee does not constitute a loss of the confidential or privileged nature of the communication. Any other distribution, use or reproduction is unauthorized and prohibited. If you are not the intended recipient, please contact the sender by return electronic mail and delete all copies of this communication |
|
From: Paul F. <fer...@gm...> - 2025-07-17 07:52:46
|
On Thu, Jul 17, 2025 at 12:28:16PM +0800, Zixian Zeng wrote: > On Wed, Jul 16, 2025 at 11:42:06AM +0300, Paul Fertser wrote: > > On Wed, Jul 16, 2025 at 01:01:37PM +0800, Zixian Zeng wrote: > > > I like using OpenOCD and GDB to debug programs on STM32. On STM32 I just > > > need to do > > > > openocd -f board/stm32f3discovery.cfg > > > > arm-none-eabi-gdb <executable> #in other terminal > > > And using `tar ext :3333` > > > > Good to hear you like it and it's easy with STM32F3, your commands are > > correct. BTW, you can use gdb-multiarch (or just gdb on Fedora) from > > your distro repository, no need for a special arm-none-eabi version. > > > Thanks for your suggestion, but I use Gentoo as Linux distribution, > which doesn't have gdb-multiarch package. :-( But it has "multitarget" USE flag for GDB ebuild. > > > I found board/ti_mspm0_launchpad.cfg in mainline repo, and using the > > > latest openocd right away. I can connect to the board and program it. > > > But I can not debug it > > > > What exactly "can not debug" implies? You can see full interaction > > between GDB and OpenOCD if you do "set debug remote 1" before running > > "target" command. > > > I try enable the debug information and dump the log to: > https://nopaste.net/sDiGiAeWyS Are you sure there's anything inside that while (1) loop you're trying to step through? Please look through the disassembly. Also try going instruction by instruction with "stepi". > > > and nothing happens when I reset board through GDB "monitor > > > mspm0_board_reset" command. > > > > That is a special command to simulate power on reset it seems. Why > > exactly are you trying to use it, what you expect and what actually > > happens? > > > > Simply I want to reset the board and let it execute the first > instruction. Then it would be "mon reset halt" and then "si". > I also try using "monitor reset [halt]" but nothing > happens. It can not be nothing, and it's not there in your log. Monitor commands is something GDB doesn't track, they're just passed through, so if you something like "mon reset halt" and you want to see the result in GDB you need to do "mon gdb_sync" and then "si" to let GDB sync. BTW, "reset" without argument is "reset run" so a different command, it doesn't even try to halt. > So I doubt that I can not use GDB debugging programs compiled by > "tiarmclang". Or can I use GNU toolchain to develop MSPM0G3507-LaunchPad ? GDB seem to be picking up debugging info from your ELF file properly, at least your current log doesn't show anything obviously wrong about it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Zixian Z. <syc...@gm...> - 2025-07-17 04:28:33
|
On Wed, Jul 16, 2025 at 11:42:06AM +0300, Paul Fertser wrote: > Hi Zixian, > > On Wed, Jul 16, 2025 at 01:01:37PM +0800, Zixian Zeng wrote: > > I like using OpenOCD and GDB to debug programs on STM32. On STM32 I just > > need to do > > > openocd -f board/stm32f3discovery.cfg > > > arm-none-eabi-gdb <executable> #in other terminal > > And using `tar ext :3333` > > Good to hear you like it and it's easy with STM32F3, your commands are > correct. BTW, you can use gdb-multiarch (or just gdb on Fedora) from > your distro repository, no need for a special arm-none-eabi version. > Thanks for your suggestion, but I use Gentoo as Linux distribution, which doesn't have gdb-multiarch package. :-( > > I found board/ti_mspm0_launchpad.cfg in mainline repo, and using the > > latest openocd right away. I can connect to the board and program it. > > But I can not debug it > > What exactly "can not debug" implies? You can see full interaction > between GDB and OpenOCD if you do "set debug remote 1" before running > "target" command. > I try enable the debug information and dump the log to: https://nopaste.net/sDiGiAeWyS At the same time, the OpenOCD side shows the error messages: Info : Listening on port 3333 for gdb connections Info : accepting 'gdb' connection on tcp/3333 [mspm0x.cpu] halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0000016a msp: 0x20208000 Info : Data region NOT available! Info : [mspm0x.cpu] Not running when halt was requested, stopping GDB. (state=2) Info : [mspm0x.cpu] Not running when halt was requested, stopping GDB. (state=2) Info : [mspm0x.cpu] Not running when halt was requested, stopping GDB. (state=2) > > and nothing happens when I reset board through GDB "monitor > > mspm0_board_reset" command. > > That is a special command to simulate power on reset it seems. Why > exactly are you trying to use it, what you expect and what actually > happens? > Simply I want to reset the board and let it execute the first instruction. I also try using "monitor reset [halt]" but nothing happens. Since that I find the "mspm0_board_reset" command from the help page. > > Info : accepting 'gdb' connection on tcp/3333 <----- GDB attaching > > [mspm0x.cpu] halted due to debug-request, current mode: Thread > > xPSR: 0x01000000 pc: 0x0000016a msp: 0x20208000 > > Info : Data region NOT available! > > Everything looks correct so far. The last message means target MCU > doesn't have any dedicated data flash region but that's to be > expected, right? > Yes, you're right, so I think the problem is mainly caused by the error messages above. > > I want to ask if the GDB debugging feature is under developing or I used > > it incorrectly? Thanks for any suggestions. > > It should just work, Cortex-M is not a new target. > I hope it will, thanks you very much. I want to say one thing, which might important. Or not? I'm not sure. On STM32 platform which I rather familiar with I compile my code using the full GNU toolchain. But I'm not familiar with TI MSPM0G3507-LaunchPad so far, I used the CCS (Code Composer Studio™ integrated development environment) provided by TI and compiled code in "tiarmclang" tool chain. So I doubt that I can not use GDB debugging programs compiled by "tiarmclang". Or can I use GNU toolchain to develop MSPM0G3507-LaunchPad ? > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fer...@gm... Best regards, Zixian |
|
From: Paul F. <fer...@gm...> - 2025-07-16 08:42:19
|
Hi Zixian, On Wed, Jul 16, 2025 at 01:01:37PM +0800, Zixian Zeng wrote: > I like using OpenOCD and GDB to debug programs on STM32. On STM32 I just > need to do > > openocd -f board/stm32f3discovery.cfg > > arm-none-eabi-gdb <executable> #in other terminal > And using `tar ext :3333` Good to hear you like it and it's easy with STM32F3, your commands are correct. BTW, you can use gdb-multiarch (or just gdb on Fedora) from your distro repository, no need for a special arm-none-eabi version. > I found board/ti_mspm0_launchpad.cfg in mainline repo, and using the > latest openocd right away. I can connect to the board and program it. > But I can not debug it What exactly "can not debug" implies? You can see full interaction between GDB and OpenOCD if you do "set debug remote 1" before running "target" command. > and nothing happens when I reset board through GDB "monitor > mspm0_board_reset" command. That is a special command to simulate power on reset it seems. Why exactly are you trying to use it, what you expect and what actually happens? > Info : accepting 'gdb' connection on tcp/3333 <----- GDB attaching > [mspm0x.cpu] halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x0000016a msp: 0x20208000 > Info : Data region NOT available! Everything looks correct so far. The last message means target MCU doesn't have any dedicated data flash region but that's to be expected, right? > I want to ask if the GDB debugging feature is under developing or I used > it incorrectly? Thanks for any suggestions. It should just work, Cortex-M is not a new target. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Zixian Z. <syc...@gm...> - 2025-07-16 05:01:50
|
Hi, dear OpenOCD users and developers: I'm new bird and currently trying to changing developing board from STM32F3-discovery to TI MSPM0G3507-LaunchPad. I like using OpenOCD and GDB to debug programs on STM32. On STM32 I just need to do > openocd -f board/stm32f3discovery.cfg > arm-none-eabi-gdb <executable> #in other terminal And using `tar ext :3333` I found board/ti_mspm0_launchpad.cfg in mainline repo, and using the latest openocd right away. I can connect to the board and program it. But I can not debug it and nothing happens when I reset board through GDB "monitor mspm0_board_reset" command. Log below: $ sudo openocd -f board/ti_mspm0_launchpad.cfg Open On-Chip Debugger 0.12.0+dev-01084-gcbc32c383 (2025-07-15-10:33) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Warn : DEPRECATED: auto-selecting transport "swd". Use 'transport select swd' to suppress this message. Warn : Transport "swd" was already selected cortex_m reset_config sysresetreq Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : XDS110: connected Info : XDS110: vid/pid = 0451/bef3 Info : XDS110: firmware version = 3.0.0.38 Info : XDS110: hardware version = 0x0028 Info : XDS110: connected to target via SWD Info : XDS110: SWCLK set to 2500 kHz Info : clock speed 10000 kHz Info : SWD DPIDR 0x6ba02477 Info : [mspm0x.cpu] Cortex-M0+ r0p1 processor detected Info : [mspm0x.cpu] target has 4 breakpoints, 2 watchpoints Info : [mspm0x.cpu] Examination succeed Info : [mspm0x.cpu] starting gdb server on 3333 Info : Listening on port 3333 for gdb connections Info : accepting 'gdb' connection on tcp/3333 <----- GDB attaching [mspm0x.cpu] halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0000016a msp: 0x20208000 Info : Data region NOT available! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I want to ask if the GDB debugging feature is under developing or I used it incorrectly? Thanks for any suggestions. Best regards, Zixian |
|
From: Paul F. <fer...@gm...> - 2025-06-22 18:25:23
|
On Sun, Jun 22, 2025 at 09:51:53AM -0700, Thomas D. Dean wrote: > Here is the question: Why did cycling power also fix the problem? There is > no OS, so memory use should be static. Something in core 0 is using the > stack allocated to core1_main. Maybe in cyw43? I don't think pico-sdk. I suspect some race condition. What OpenOCD does (have to) is using SYSRESETREQ on one core, then on the other (probably, not sure, haven't worked with SMP targets like that, you can see what exactly is happening in that regard with -d3 option). While Power-On-Reset I guess is doing it simultaneously so they start running (or the second core starts stopped?) at the same time. Regular targets just have an external RESET (SRST) signal which adapter pulls down same as a reset button or external watchdog would. I do not have a good explanation of why it can lead exactly to what you describe (I'm not sure what "starting core 1" and "exiting main" implies on this platform to begin with). I wonder if it behaves differently if you instead try -c "program /path/to.elf verify; reset halt; resume; shutdown" (reset halt should make the cores stop at reset vector first) > Thanks for your help. Sorry for the noise. We did find one problem. Is > someone going to make the change in git? Eventually, yes :) Thank you for reporting it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Thomas D. D. <to...@wa...> - 2025-06-22 16:52:00
|
On 6/21/25 22:23, Paul Fertser wrote: I found a what but not a why. Near the start of main, I launch core 1. core1_main starts some DMA, PIO, allocates an alarm pool starts a repeating timer, then exits. For now, there is nothing for core1_main to do. All the action of core 1 is in the timer callback, DMA, or PIO. Stopping core1_main from exiting fixed the problem. Interestingly, delaying the exit of core1_main by 250 msec, also fixed the problem. The alarm pool variable was on the stack! If core1_main exited too soon, something messed up core 0 and the web page was not available. The repeating timer fired at least one time after core1_main exited. Making the alarm pool variable static (as it should have been) also fixed the problem. This will be mixed with some code I don't control, so I want to limit variable scope. Here is the question: Why did cycling power also fix the problem? There is no OS, so memory use should be static. Something in core 0 is using the stack allocated to core1_main. Maybe in cyw43? I don't think pico-sdk. Thanks for your help. Sorry for the noise. We did find one problem. Is someone going to make the change in git? Tom Dean |
|
From: Paul F. <fer...@gm...> - 2025-06-22 05:23:43
|
On Sat, Jun 21, 2025 at 04:28:33PM -0700, Thomas D. Dean wrote: > On 6/21/25 15:49, Paul Fertser wrote: > > On Sat, Jun 21, 2025 at 03:31:56PM -0700, Thomas D. Dean wrote: > > > If I > > > 1. connect the RPi debug probe to USB and pico_w. > > > 2. power on the pico_w. > > > 3. sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg \ > > > -c "adapter speed 5000" -c "program $1 verify reset exit" > > > > This looks correct, I have nothing to suggest here. > > > > > Openocd seems to finish without error. > > > > > > Attempting to connect with firefox never does, just sets there > > > spining. > > > > And here I would suggest to connect with GDB to see what it is doing > > and why it is stuck where. > > > > > I noticed that cmake says the build type for my project is release, the > > > *.elf file has debug symbols. and openocd output has debug and breakpoint. > > > > Debug symbols are used by GDB, OpenOCD doesn't parse any of it from > > ELF. And BTW, adding full debug information doesn't increase the > > amount of flash used, it's all in special ELF sections which are not > > copied to the target at all. > > > > I looked with gdb. The code is in a while loop, waiting for the html, as it > should be. > > The only concern is the need to cycle power after writing flash. I hope looking with GDB before power cycling should provide the clues about what specifically is different with power-on-reset vs. SYSRESETREQ. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
14 messages has been excluded from this view by a project administrator.
