It says you should look for a binary at the board seller first.
==================
Installing OpenOCD
==================
A Note to OpenOCD Users
-----------------------
If you would rather be working "with" OpenOCD rather than "on" it, your
operating system or JTAG interface supplier may provide binaries for
you in a convenient-enough package.
Such packages may be more stable than git mainline, where
bleeding-edge development takes place. These "Packagers" produce
binary releases of OpenOCD after the developers produces new "release"
versions of the source code. Previous versions of OpenOCD cannot be
used to diagnose problems with the current release, so users are
encouraged to keep in contact with their distribution package
maintainers or interface vendors to ensure suitable upgrades appear
regularly.
Users of these binary versions of OpenOCD must contact their Packager to
ask for support or newer versions of the binaries; the OpenOCD
developers do not support packages directly.
A Note to OpenOCD Packagers
---------------------------
You are a PACKAGER of OpenOCD if you:
- Sell dongles and include pre-built binaries;
- Supply tools or IDEs (a development solution integrating OpenOCD);
- Build packages (e.g. RPM or DEB files for a GNU/Linux distribution).
As a PACKAGER, you will experience first reports of most issues.
When you fix those problems for your users, your solution may help
prevent hundreds (if not thousands) of other questions from other users.
If something does not work for you, please work to inform the OpenOCD
developers know how to improve the system or documentation to avoid
future problems, and follow-up to help us ensure the issue will be fully
resolved in our future releases.
That said, the OpenOCD developers would also like you to follow a few
suggestions:
- Send patches, including config files, upstream, participate in the
discussions;
- Enable all the options OpenOCD supports, even those unrelated to your
particular hardware;
- Use "ftdi" interface adapter driver for the FTDI-based devices.
Ok that explains it then.
How do you get the git master and add the patch to it?
Ok I managed that part, did a
git clone https://github.com/openocd-org/openocd and then a
git fetch https://review.openocd.org/openocd refs/changes/43/6543/5 && git checkout -b change-6543 FETCH_HEADThat seemed to work.
Then how to compile? I am on windows.
Don't know about Windows but on Linux/MacOS you run:
./bootstrap
./configure
make
sudo make install
It doesn't seem to parallel build correctly, so something like "make -j12" won't work.
You will likely encounter things missing when running the configure script. Things like libusb. Install and run again. Not sure how this works on Windows.
Gosh it's insane the amount of time necessary to get that bloody thing working.
So I've got a compiled OpenOCD with the patch. I am using Visual Studio Code with the cortex-debug extension and the following config:
{
"name": "CMSIS-DAP OpenOCD",
"cwd": "${workspaceRoot}",
"executable": "./debug/gd32-gcc-test.elf",
"request": "launch",
"type": "cortex-debug",
"servertype": "openocd",
"serverpath": "C:/Program Files/OpenOCD/bin/openocd.exe",
"configFiles": [
"board/gd32e230-start.cfg"
],
"interface": "swd",
"device": "GD32E230",
"svdFile": "GD32E230.svd",
"runToEntryPoint": "main",
"armToolchainPath": "C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.10/bin",
"preRestartCommands": [
"load",
"continue"
]
}I get really weird things when GDB starts - the PC is set to 0x2000003a?!
Anyways - then I run "load" and "continue" and everything seems fine, the PC goes back to where it should and the hardware automatically stops when it reaches main().
I thought the preRestartCommands would run automatically? Not much info about it here:
https://github.com/Marus/cortex-debug/wiki/Common-Configuration-Properties
"load" is for use when working with a non-remote GDB. It attempts to debug an executable locally.
"file" tells GDB to load a file and use it for symbols, but doesn't affect what's running. This is more useful when attaching to running firmware or a running process locally.
I use something like this to flash:
monitor reset halt
monitor flash write_image erase build_debug/image 0 elf
file build_debug/image
"monitor" sends a command to OpenOCD, which does the flashing.
Usually when attaching to a running device I'll just halt with "monitor halt". (In fact, I have this in the gdbinit)
In your case it seems like you might want something more basic, like:
"preRestartCommands": [
"monitor halt",
]
"stop" might also work, but relies on GDB being able to determine the state of the target. If it can't it assumes it's already stopped and a "stop" command won't do anything.
hi, I'm struggling with gd32e230 using gcc under linux,
now it can NOT boot at all, could you please share a simple vscode project with gcc,
many thanks
