K210 Register Definition File (RDF)

[MyAmigo]

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, 9 months ago by MyAmigo.
• This topic was modified 4 years, 9 months ago by MyAmigo.
• This topic was modified 4 years, 9 months ago by MyAmigo.
• This topic was modified 4 years, 9 months ago by support. Reason: attached the link from the separate post

[support]

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.

[MyAmigo]

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, 9 months ago by MyAmigo.

[support]

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.

[MyAmigo]

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!

 

 

 

[MyAmigo]

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.

• 0x52000000: https://photos.app.goo.gl/mZkqCchNR8AtaQ59A
• 0x50300000: https://photos.app.goo.gl/oCTc9BdndQ9jzkjP8

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, 9 months ago by MyAmigo.

[support]

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.

[MyAmigo]

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)

 

 

[support]

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.

[MyAmigo]

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

 

[support]

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.

[MyAmigo]

OK

Thanks for your help.

[Author]

Posts