sysprogs / openocd Goto Github PK

Hi, when I build master branch, 1e2be7e, some error happend
Undefined symbols for architecture x86_64:
"_msp432p4_flash", referenced from:
_flash_drivers in libopenocd.a(drivers.o)
"_multicore_rtos", referenced from:
_rtos_create in libopenocd.a(src_rtos_librtos_la-rtos.o)
_rtos_qsymbol in libopenocd.a(src_rtos_librtos_la-rtos.o)
_rtos_try_next in libopenocd.a(src_rtos_librtos_la-rtos.o)
_rtos_types in libopenocd.a(src_rtos_librtos_la-rtos.o)
"_plugin_flash", referenced from:
_flash_drivers in libopenocd.a(drivers.o)
"_stm32h7x_flash", referenced from:
_flash_drivers in libopenocd.a(drivers.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/openocd] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I tried to build this project in ubuntu，but failed.
so is it possiable to build under Ubuntu?

Hello,
i've been trying VisualGBD lately and experimenting to modify the CMakeLists.txt to generate a dll instead of an executable but it appears you can't just change the add_executable entry to add_library. The project generates a lot of linker errors then.

(add_library(openocd SHARED openocd.c main.c hello.c ${CMAKE_CURRENT_BINARY_DIR}/startup_tcl.inc)

Could anybody please be so kind and drop a working CMakeLists.txt or instructions on how to convert that project ? I happily buy a license or donate something to this project if someone is able to help out. Thank you very much!

As the title says, adding support for PEMicro debug probes would be greatly beneficial. This support is already added in pyOCD via a plugin pyOCD-PEMicro Github page

I've compiled openocd from github fork raspberrypi/openocd branch picoprobe. When I execute openocd --file picoprobe.cfg --file nrf52.cfg I see the following error:

../share/openocd/scripts/target/swj-dp.tcl:30: Error: Unknown param: 0x2ba01477, try one of: -irlen, -irmask, -ircapture, -enable, -disable, -expected-id, -ignore-version, -dp-id, or -instance-id
in procedure 'script' 
at file "embedded:startup.tcl", line 26
in procedure 'swj_newdap' called at file "nrf52.cfg", line 27
at file "../share/openocd/scripts/target/swj-dp.tcl", line 30

Both .cfg files are form the installed scripts folder.

Hi all. I can't debug my code on my stm32f1xxx based board with my stlink v3. Two days ago i could do it without problems.

This is the error that i get in the testing functionality.

C:\Users\Jacar\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\bin\openocd.exe -c "gdb_port 50064" -c "telnet_port 50063" -f interface/stlink.cfg -f target/stm32f1x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"
Open On-Chip Debugger 0.10.0 (2020-03-10) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Info : STLINK v3 JTAG v5 API v3 SWIM v1 VID 0x0483 PID 0x374F
Info : using stlink api v3
Info : Target voltage: 3.296598
Info : Stlink adapter speed set to 1000 kHz
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 50064 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
VisualGDB_OpenOCD_Ready
Error: couldn't bind tcl to socket on port 6666: No error

Hi,

I cannot get this to (easily) build on Ubuntu 22.04 LTS because of numerous size mismatches.

I fixed some, and removed the -Werror to get it to continue without stopping, but stil lhave problems with ERROR_BAD_ARGUMENTS and ERROR_INSUFFICIENT_BUFFER being undefined in src/target/target.c.

DAVE

Doing QSPI init at reset-end causes it to happen whenever any type of reset happens. This includes reset run, in which the CPU is not halted. Then initialization happens while the CPU is running. This leads to a race condition if user code also initializes the QSPI or does pin muxing, with the end result of register corruption and undefined behavior.

This type of initialization should instead be done in reset-init according to OpenOCD documentation:

This [reset-init] is where you would configure PLLs and clocking, set up DRAM so you can download programs that don’t fit in on-chip SRAM, set up pin multiplexing, and so on. (You may be able to switch to a fast JTAG clock rate here, after the target clocks are fully set up.)

and also OpenOCD developers confirm it:

(11:42:22) PaulFertser: ali1234: some targets use reset-end for disabling watchdog
(11:42:27) PaulFertser: ali1234: because it makes sense for debugging
(11:42:37) PaulFertser: alan_o: initialising flash controller centainly doesn't belong there.
(11:42:41) PaulFertser: ali1234: ^^
(11:58:47) PaulFertser: ali1234: reset-init handler is usually used to initialise flash/RAM/etc, whatever is needed for flashing the device, and it's called only during "reset init", not even during "reset halt".
(11:59:17) PaulFertser: ali1234: so "program" script uses "reset init" automatically prior to trying to write to flash.
(12:04:42) ali1234: so now i understand why you said "it initializes itself"
(12:05:27) ali1234: because "reset-end" is always run, even when we are not programming - and we only want openocd to init the chip when programming, otherwise the app code should do it
(12:05:45) ali1234: ie it should do it itself in that case
(12:16:15) PaulFertser: ali1234: yes, that's what I meant. Code like that belong to reset-init handler and programming procedure should involve "reset init" command somehow. E.g. default handlers for GDB events includes that prior to erasing the flash.

The patch set being developed upstream also performs the initialization in reset-init:

http://openocd.zylin.com/#/c/4321/
http://openocd.zylin.com/#/c/4321/7/tcl/board/nucleo-h743zi.cfg <- line 126, triggers qspi_init in reset-init

The commit adding stm32h7x_dual_core.cfg claims to be ported from git.ac6.fr, however I cannot find it anywhere in that repository, so it is not clear to me where it came from.

Hey,
I got various compilation errors on a recent Debian distribution.

GCC Version:

gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compilation errors:

In file included from ./src/jtag/jtag.h:15,
                 from src/openocd.c:20:
./src/flash/nor/core.h: In function ‘report_flash_progress’:
./src/flash/nor/core.h:283:11: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 7 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
  283 |  LOG_INFO("%s:0x%llx|0x%llx|%s", op, region_start, region_end, block_name);
      |           ^~~~~~~~~~~~~~~~~~~~~      ~~~~~~~~~~~~
      |                                      |
      |                                      uint64_t {aka long unsigned int}
./src/helper/log.h:118:60: note: in definition of macro ‘LOG_INFO’
  118 |  log_printf_lf(LOG_LVL_INFO, __FILE__, __LINE__, __func__, expr)
      |                                                            ^~~~
In file included from src/openocd.c:24:
./src/flash/nor/core.h:283:20: note: format string is defined here
  283 |  LOG_INFO("%s:0x%llx|0x%llx|%s", op, region_start, region_end, block_name);
      |                 ~~~^
      |                    |
      |                    long long unsigned int
      |                 %lx
In file included from ./src/jtag/jtag.h:15,
                 from src/openocd.c:20:
./src/flash/nor/core.h:283:11: error: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 8 has type ‘uint64_t’ {aka ‘long unsigned int’} [-Werror=format=]
  283 |  LOG_INFO("%s:0x%llx|0x%llx|%s", op, region_start, region_end, block_name);
      |           ^~~~~~~~~~~~~~~~~~~~~                    ~~~~~~~~~~
      |                                                    |
      |                                                    uint64_t {aka long unsigned int}
./src/helper/log.h:118:60: note: in definition of macro ‘LOG_INFO’
  118 |  log_printf_lf(LOG_LVL_INFO, __FILE__, __LINE__, __func__, expr)
      |                                                            ^~~~
In file included from src/openocd.c:24:
./src/flash/nor/core.h:283:27: note: format string is defined here
  283 |  LOG_INFO("%s:0x%llx|0x%llx|%s", op, region_start, region_end, block_name);
      |                        ~~~^
      |                           |
      |                           long long unsigned int
      |                        %lx
In file included from ./src/jtag/jtag.h:15,
                 from src/openocd.c:20:
src/openocd.c: In function ‘setup_command_handler’:
src/openocd.c:272:24: error: expected ‘)’ before ‘LIBUSB1_COMMIT’
  272 |  LOG_OUTPUT("libusb1 " LIBUSB1_COMMIT "\n");
      |                        ^~~~~~~~~~~~~~
./src/helper/log.h:133:59: note: in definition of macro ‘LOG_OUTPUT’
  133 |  log_printf(LOG_LVL_OUTPUT, __FILE__, __LINE__, __func__, expr)
      |                                                           ^~~~
In file included from src/openocd.c:24:
At top level:
./src/flash/nor/core.h:281:13: error: ‘report_flash_progress’ defined but not used [-Werror=unused-function]
  281 | static void report_flash_progress(const char *op, uint64_t region_start, uint64_t region_end, const char *block_name)
      |             ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors

Any ideas?

stm32l4x option_read and stm32l4x option_write uses incorrect base address (or at least for the STM32L43x family of MCUs, I did not verify the Option Byte addresses of other STM32L4x MCUs).

The base address currently used by OpenOCD is 0x40022000, this should be 0x1FFF7800, and as a result any calls to stm32l4x option_read and stm32l4x option_write fails to read/write the option bytes of an STM32L43x MCU.

Error connecting DP: cannot read IDR