Kendryte JlinK Jtag not working

[Johanan]

Hi,

Trying to start working with K210, but Some exception with JLink

See attached screenshots.

I tried with an old and a new JLink, also tried to use ST-LINK as Jtag, no joy.

Thanks

Johanan

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Please see the following page for instructions on troubleshooting common OpenOCD issues: https://visualgdb.com/documentation/openocd/troubleshooting/

[Johanan]

I maneged to run the debug test OK. (see attached screen).

However when starting debug the GDB is halted, see attached screens and file. As you can see I waited the full 5 minutes as suggested in the generic GDB help page…

Thanks

Johanan

 

Attachments:

You must be logged in to view attached files.

[support]

Based on our experiments, the Kendryte port of OpenOCD is extremely unreliable. You can find more details and possible workarounds in our Kendryte tutorial, or by contacting Kendryte for further help.

[Johanan]

well, I tried with Olimex Jtag same as in your tutorial, and Jlink.

In both cases it passes the test connection, but fail to program the chip.

As far as I got to Kendryte support, I got only some tips (in Chines, I used Google translate) how to use it on Linux with command line compile/debug which is a pain for me, I haven’t tried it yet as it will consume too much time.

Any ideas?

Thanks

[support]

Sorry, we don’t have any ideas why the Kendryte OpenOCD port would not work with a specific Kendryte chip. We do our best to integrate the tools from different vendors with our products, but sometimes the underlying tools just won’t work.

[Johanan]

Thank for your efforts, it looks like I am “falling between the chairs”.

as of now Kendryte support don’t know what

invalid subcommand “protect 0 64 last off”
in procedure ‘flash’

Means, maybe you have an idea? The only thing that comes to mind is that K210 does not have an internal flash (program is uploaded to ram and run from ram), why ‘flash’ procedure.

As you can see there is connection, it finds the two cores RISCV, and fail at this flash procedure, any ideas will be appreciated.

<hr />

C:\Users\Johanan\AppData\Local\VisualGDB\EmbeddedDebugPackages\com.sysprogs.riscv.openocd-kendryte\bin\openocd.exe -c “gdb_port 4417” -c “telnet_port 4418” -f interface/jlink.cfg -c “adapter_khz 4000” -f target/kendryte.cfg -c init -c “reset init” -c “echo VisualGDB_OpenOCD_Ready”
_ __ _ _
| |/ /___ _ __ __| |_ __ _ _| |_ ___
| ‘ // _ \ ‘_ \ / _` | ‘__| | | | __/ _ \
| . \ __/ | | | (_| | | | |_| | || __/
|_|\_\___|_| |_|\__,_|_| \__, |\__\___|
|___/
Kendryte Open On-Chip Debugger For RISC-V v0.2.3 (2019-02-21)
Licensed under GNU GPL v2
adapter speed: 4000 kHz
Info : auto-selecting first available session transport “jtag”. To override use ‘transport select <transport>’.
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
Info : J-Link ARM V8 compiled Dec 1 2009 11:42:48
Info : Hardware version: 8.00
Info : VTarget = 3.267 V
Info : clock speed 4000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x04e4796b (mfg: 0x4b5 (<unknown>), part: 0x4e47, ver: 0x0)
Core [1] halted at 0x80005f10 due to debug interrupt
Info : Examined RISCV core; found 2 harts
Info : Listening on port 4417 for gdb connections
Info : JTAG tap: riscv.cpu tap/device found: 0x04e4796b (mfg: 0x4b5 (<unknown>), part: 0x4e47, ver: 0x0)
VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4418 for telnet connections
Info : accepting ‘gdb’ connection on tcp/4417
Info : JTAG tap: riscv.cpu tap/device found: 0x04e4796b (mfg: 0x4b5 (<unknown>), part: 0x4e47, ver: 0x0)
invalid subcommand “protect 0 64 last off”
in procedure ‘flash’

 

 

[Johanan]

Hi,

Trying to understand the source of the problem I contacted Olimex support, which replied with  this detailed answer:

<hr />

<pre class=”moz-quote-pre”>Hello,

Seems like software mismatch or software misconfiguration. The log until
that point seems fine, device is found and connection is established. It
seems like a problem occurs when the command to remove the flash
protection is executed. Maybe you are not trying to write to the flash,
maybe the chip has no flash, maybe extra parameters are needed
specifically for this chip? I can’t say. Maybe a command from the list
of commands is not compatible with the OpenOCD version used by the
software you are using OR with the chip.
Check if you are using newest software for the chip.
You might also try to find in the software setup the line:

monitor flash protect 0 64 last off

and comment it out and try again.

It is clear that the issue is not caused by ARM-USB-OCD. If the problem
remains, please, direct your questions to the Kendryte, VisualGDB,
RISC-V, and OpenOCD communities. I would recommend posting in the SiFive forums

<pre class=”moz-quote-pre”>———————————————————
Can you tell me how to change the OpenOCD script in VisualGDB, so I can make changes?
Thanks,
Johanan

[support]

Sorry, we are not the vendor for the Kendryte OpenOCD port.

If you can manage to get it working by running OpenOCD manually, please let us know the command line that worked and we will help you configure VisualGDB to use it as well. If OpenOCD is not working with the specific chip outside VisualGDB, it will not work when using VisualGDB either.

[Johanan]

I got the gdb server listening on port 3333 in a cmd shell window. (see  screens).

Can you show me correct config for custom GDB stub, and how I can start a GDB manual session from within Visual Studio?

Thanks

Attachments:

You must be logged in to view attached files.

[support]

No problem. First of all, please try testing the session manually by running the following command from the Command Prompt window:

c:\sysgcc\kendryte\bin\riscv64-unknown-elf-gdb.exe <full path to the ELF file>

The path to ELF file is typically <project directory>\VisualGDB\Debug\<project name without extension>

Then, run the following commands in the gdb session:

target remote :3333
load
break main
continue

If this results in a usable debug session (i.e. breakpoint in main() hits), you can configure VisualGDB to replicate this as shown below:

Once the manual mode works, feel free to adjust the command line used by VisualGDB to match it:

If you can point specific command line differences that resolve the problem on your side, we will be happy to update VisualGDB to automatically apply them. Also if you can confirm that the OpenOCD from kendryte works, while the executable shipped VisualGDB doesn’t, we can double-check it on our side (it’s built from the official Kendryte sources, so it should be equivalent).

• This reply was modified 3 years, 7 months ago by support.

Attachments:

You must be logged in to view attached files.

[Johanan]

Well, I am not absolutely sure what happen here, but it started working, maybe after updating latest Kendryte package.

see attached screen.

Only thing that bothers me is the:

invalid subcommand “protect 0 64 last off”
in procedure ‘flash’

And:

invalid command name “mbatch”

how can these be removed?

It waits 2-3 seconds after the first invalid subcommand, then hit the breakpoint.

The dev board is connected via USB com port, which I connected to power the chip, and 20pins regular cable to Jlink, which is also connected to a USB port.

There is some link between the com port and the debugger, as when I try to open a terminal utility on this com port, the debugger crashes, I don’t know why/ I will try to investigate this and send you info if I can find anything.

BR Johanan

 

Attachments:

You must be logged in to view attached files.

[support]

The protect and mbatch commands come from the regular RISC-V debug logic and can be safely ignored for Kendryte devices.

BTW, thanks for sharing the solution you discovered with the JTAG pins. We have moved it to a separate thread to make it easier for other users to find it.

[Author]

Posts