Debugging MaixGo on PlatformIO using Kendryte standalone SDK about platform-kendryte210 HOT 13 CLOSED

1. Please switch to the latest upstream version http://docs.platformio.org/en/latest/platforms/kendryte210.html#upstream
2. You need to configure debug_tool. See currently supported https://github.com/sipeed/platform-kendryte210/blob/master/platform.py#L42

For example,

[env:sipeed-maix-go]
platform = kendryte210
framework = kendryte-standalone-sdk
board = sipeed-maix-go
monitor_speed = 115200
debug_tool = jlink
build_type = debug

See a demo from my sipeed-maix-bit

from platform-kendryte210.

@btx000, @GitJer , please re-test.

There are some issues with Kendryte toolchain where it returns a fake list of CSR* registers. We reported this to RISC-V official team and they fixed this bug a lot of months ago. It seems that @kendryte uses very old fork of RISC-V GCC. Ping @vowstar, @sunnycase. Can we use official RISC-V GCC toolchain?

from platform-kendryte210.

Please note that uploading through "upload_protocol" currently does not work. See issue kendryte/openocd-kendryte#11

from platform-kendryte210.

But you are using an external debugger right? (I see Olimex on the config).

Can't I use the internal debugger from the MaixGo board?

from platform-kendryte210.

Does MaixGo have an internal debugger? I didn't see it.

from platform-kendryte210.

According to the docs, yes: http://docs.platformio.org/en/latest/boards/kendryte210/sipeed-maix-go.html#debugging

But according to the comment it's still not implemented or working: #9 (comment)

from platform-kendryte210.

This is old and invalid docs. It was a mistake by @btx000. We will release a new version soon and re-generate docs.

@btx000 am I correct? MaixGo does not have on-board debugger?

from platform-kendryte210.

@ivankravets Maix go board has an open-ec firmware based onboard debugger (using stm32 emulation ftdi2232), but the current version is not perfect, we are working for it.

from platform-kendryte210.

@btx000 please ping me when it will be supported.

from platform-kendryte210.

@Posting here to track this bug, I am unable to debug as well. Please keep us posted whenever we can debug this.

from platform-kendryte210.

I had success with Flyswatter rev B to debug, which is another FTDI FT2232C based board. (Two JLinks I have didn't work after many attempts.)

Single step, breakpoints, dump memory, and similar core commands seem to work now.

Command (openocd-kendryte revision 08bc16c3057be19927d6d5784e31abc208242719:)

openocd-kendryte/bin/openocd -f kendryte-flyswatter.cfg -m 0

Config file kendryte-flyswatter.cfg:

# debug adapter
interface ftdi
ftdi_device_desc "Flyswatter"
ftdi_vid_pid 0x0403 0x6010

ftdi_layout_init 0x0818 0x0cfb
ftdi_layout_signal nTRST -data 0x0010
ftdi_layout_signal nSRST -oe 0x0020
ftdi_layout_signal LED -data 0x0c00

transport select jtag
adapter_khz 3000

# server port
gdb_port 3333
telnet_port 4444

# add cpu target
set _CHIPNAME riscv

jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x04e4796b

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME

# command
init
halt

from platform-kendryte210.

Hello,
strange that I do not see mention about disabling onboard STM32 for external debug.
It is obvious that active STM32 interface will prevent successful debug via external probe.
And I do observe this collision when trying to connect J-link. J-link could not pull JTAG lines to ground.
So, there must be a way to disable STM32. Maybe by pulling reset down, but it is inconvenuet.

from platform-kendryte210.

I disabled STM32 via BOOT0 during PowerON. Now I see correct oscillograms with J-link.
My output looks like:
Kendryte Open On-Chip Debugger For RISC-V v0.2.3 (2019-02-21) Licensed under GNU GPL v2 debug_level: 2 adapter speed: 1000 kHz Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'. riscv.cpu Info : J-Link V9 compiled Sep 1 2016 18:29:50 Info : Hardware version: 9.20 Info : VTarget = 3.269 V Info : clock speed 1000 kHz Info : JTAG tap: riscv.cpu tap/device found: 0x04e4796b (mfg: 0x4b5 (<unknown>), part: 0x4e47, ver: 0x0) Core [0] halted at 0x404 due to software breakpoint Info : Examined RISCV core; found 2 harts Info : Listening on port 3333 for gdb connections Info : JTAG tap: riscv.cpu tap/device found: 0x04e4796b (mfg: 0x4b5 (<unknown>), part: 0x4e47, ver: 0x0) ** Programming Started ** embedded:startup.tcl:476: Error: ** Programming Failed ** in procedure 'program' in procedure 'program_error' called at file "embedded:startup.tcl", line 532 at file "embedded:startup.tcl", line 476 *** [upload] Error 1
Segger Jlink says that my J-link does not support this RISKV debug via JTAG. Could it be a reason?
PS
If I do not use upload via J-link, debug starts and works correctly. So Segger is no right.

from platform-kendryte210.