K210 Register Definition File (RDF)

Sysprogs forums Forums VisualGDB K210 Register Definition File (RDF)

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #27156
    MyAmigo
    Participant

    Hello,

    I’m tring to get something put together so I can debug the K210’s Audio Processing Unit (APU) more easily.

    I followed the guide at http://visualgdb.com/documentation/hwregs to create a simple RDF for the first two APU registers. That file is attached to this post. I determined the register addresses and subregister fields from SDK source as follows:

    APU.C (22)

    #define BEAFORMING_BASE_ADDR (0x50250200)

    APU.H (253)

    typedef struct _apu_reg
    {
    //0x200
    apu_ch_cfg_t bf_ch_cfg_reg;
    //0x204
    apu_ctl_t bf_ctl_reg;
    //0x208 ...

    Subregister fields are also defined in apu.h …

    line 45: typedef struct _apu_ch_cfg { ... }
    line 107: typedef struct _apu_ctl_t { ... }

    The file loads without issue and when I hit a breakpoint I can open the register sections to see subregister detail…

    … but the problem is that the register values do not reflect actual memory (all 1’s) and I can’t modify them either. I would appreciate it if someone at SysProgs examined this file to see if it can be used to inspect and modify Peripheral memory.

    I have no trouble inspecting and modifying program variables so I would like to uinderstand why this is not working.

    Cheers!

    The RDF wouldn’t upload so I have provided a link >>> here <<<

    • This topic was modified 4 years, 10 months ago by MyAmigo.
    • This topic was modified 4 years, 10 months ago by MyAmigo.
    • This topic was modified 4 years, 10 months ago by MyAmigo.
    • This topic was modified 4 years, 10 months ago by support. Reason: attached the link from the separate post
    #27160
    support
    Keymaster

    Hi,

    VisualGDB uses the regular memory reading API of the underlying debug method in order to read the peripheral register values. Hence, you can easily verify whether this mechanism is working correctly by running the following commands in the GDB Session window:

    x/1x 0x<address of a register>
    monitor mdw <address>

    The first command requests the memory contents from the gdb debugger, while the second one is forwarded to OpenOCD (low-level tool for interfacing with the JTAG adapter).

    Please let us know if using the commands shown above still results in incorrect values and we will suggest further diagnostic steps.

    #27164
    MyAmigo
    Participant

    Thanks for the crazy-fast input!

    x/1x 0x50250200

    yields…

    x/1x 0x50250200
    &”x/1x 0x50250200\n”
    0x50250200: 0xffffffff
    OK

    … and that’s the same that I see with the “Hardware Register ” view. Other nearby addresses return the same result.

    When I run the monitor command I get all zeroes at that address…

    0x50250200: 00000000

    • This reply was modified 4 years, 10 months ago by MyAmigo.
    #27165
    support
    Keymaster

    No problem. If reading the memory using the GDB commands also results in invalid values, we would advise double-checking the addresses. E.g. try adding the following code to your program:

    volatile int test = *((int *)0x<address>);
    test = test;

    Then evaluate the ‘test’ in the debugger (or print it to a COM port programmatically). If the value is still -1, the address you are using is likely incorrect, or the peripheral clock has not been enabled.

    If the ‘test’ variable shows a correct value and reading the memory via GDB at the same time shows -1, it might be a bug in the Kendryte’s port of OpenOCD. If this is the case, please consider checking with Kendryte whether there is a fix for this.

    #27167
    MyAmigo
    Participant

    I think you nailed it.

    I tested several register locations at the same time. They returned the expected values and the test variables retained that value when reasigned to themselves. A bug in the K210 port of OpenOCD is the likely reason.

    Thank you!

     

     

     

    #27168
    MyAmigo
    Participant

    Just a little more info to go with this to help resolve the problem.

    I dumped memory in the region of interest andVisualGDM shows ????? for the entire address space from 0x52000000 – 0x52FFFFFF.

    This is also seems to be true for the range 0x50400000 – 0x50500000

    This should help to narrow down the cause.

    • This reply was modified 4 years, 10 months ago by MyAmigo.
    #27170
    support
    Keymaster

    Thanks for the update. It indeed looks like OpenOCD reads incorrect values. Please try reproducing the problem using the OpenOCD and gdb binaries shipped by Kendryte (OpenOCD installed by VisualGDB is built from the same sources, but there’s a tiny chance that the original Kendryte build would work differently). If you can also reproduce the issue with the original Kendryte tools, please forward this to Kendryte support. If the original tools work as expected, while VisualGDB doesn’t, please let us know and we will help you configure VisualGDB to replicate the results you get with command-line tools.

    #27171
    MyAmigo
    Participant

    I was already setup for OpenOCD debugging using tools from Kendyte’s site.

    I wish I had tried that first. Hardware registers are unsupported 🙁

    cmdlet MCU_debug.ps1 at command pipeline position 1
    Supply values for the following parameters:
    app: apu
    GNU gdb (GDB) 8.2
    Copyright (C) 2018 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Type "show copying" and "show warranty" for details.
    This GDB was configured as "--host=i686-w64-mingw32 --target=riscv64-unknown-elf".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <http://www.gnu.org/software/gdb/bugs/>.
    Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

    For help, type "help".
    Type "apropos word" to search for commands related to "word"...
    Reading symbols from apu...done.
    Remote debugging using 127.0.0.1:3333
    warning: Target-supplied registers are not supported by the current architecture
    0x0000000000000400 in ?? ()
    (gdb)

     

     

    #27172
    support
    Keymaster

    Thanks for sharing this. If the K210 OpenOCD does not support reading the peripheral registers, it might be worthwhile checking whether Segger J-Link supports it. J-Link comes with its own gdb stub that works better than OpenOCD in many non-trivial scenarios. VisualGDB supports working on top of either debug method, so if J-Link supports the K210 hardware registers, you should be able to switch very easily.

    #27181
    MyAmigo
    Participant

    Thank you for the suggestion.

    I had installed J-Link V6.48b previously so I updated to the latest beta release (V6.61d) for this trial. I assume that this is the J-Link stub you referred to… https://www.segger.com/downloads/jlink/JLink_Windows_beta.exe

    My settings with this installed are shown here: https://photos.app.goo.gl/dtGjtymNYn8a2ARM7

    When I run the connection test I get a failure…

    https://photos.app.goo.gl/dX3c8aQbbqeqhWHx5

    The failure messages are…

    Connecting to target...
    ERROR: The connected J-Link does not support selecting another hart/core than 0 for RISC-V
    Specific core setup failed.
    ERROR: Could not connect to target.

    I tried targetting the RISCV, RV32 & RV64 devices and different clock settings… Same result in each case.

    I can switch back to the OpenOCD debugger and K210 target and things are as they should be…

    https://photos.app.goo.gl/szNtbeawdKrPx5Zx8

    Do you have any further suggestions?

    Thank you

     

    #27182
    support
    Keymaster

    Sorry, this is something to check with Segger support. We are not affiliated with Segger and do not have any insights into their tools’ internals.

    #27183
    MyAmigo
    Participant

    OK

    Thanks for your help.

Viewing 12 posts - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.