Kendryte JlinK Jtag not working

Sysprogs forums Forums VisualGDB Kendryte JlinK Jtag not working

This topic contains 12 replies, has 2 voices, and was last updated by  support 6 days, 1 hour ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • #28932

    Johanan
    Participant

    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.
    #28947

    support
    Keymaster

    Hi,

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

    #28949

    Johanan
    Participant

    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.
    #28954

    support
    Keymaster

    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.

    #28974

    Johanan
    Participant

    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

    #28980

    support
    Keymaster

    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.

    #28995

    Johanan
    Participant

    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’

     

     

    #29013

    Johanan
    Participant

    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

    #29014

    support
    Keymaster

    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.

    #29015

    Johanan
    Participant

    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.
    #29018

    support
    Keymaster

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

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

    Then, run the following commands in the gdb session:

    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 1 week ago by  support.
    Attachments:
    You must be logged in to view attached files.
    #29025

    Johanan
    Participant

    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.
    #29036

    support
    Keymaster

    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.

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.