[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openocd-development
Subject:    [OpenOCD-devel] Proper GD32VF103.cfg that just works.
From:       Ein Terakawa <applause () elfmimi ! jp>
Date:       2020-11-15 5:42:57
Message-ID: cfa02b74-93d8-3af4-5d4c-c58d9b2e1bca () elfmimi ! jp
[Download RAW message or body]

I thought I could post informations I have figured out the other day
for someone should be looking for it around here.

Here is an essential configuration script to handle GD32VF103 with OpenOCD.

gd32vf103.cfg
https://gist.github.com/elfmimi/1deb9c94b0f0900ae8a9df740b62bcd6


Explanation:
With Risc-V core in GD32VF103, ndmreset has no effect.
Maybe it is because of this description in the OLD debug spec.
 > RISC-V External Debug Support
 > Version 0.13 7c760b0151e43523ab3d2180e7852cd6f27d942c
 > "What it does reset is platform-specific (it may reset nothing)."

In some cases external reset signal is used to overcome this 
shortcoming. But it is sub-optimal in terms of flawless operation.

This script introduces a improvised reset procedure which
is commenced through heavy use of dmi register access.


Note: replace 0x1e200a6d with 0x1000563d depending on your environment.
# What the heck is this idcode? see following code.
# 
https://github.com/riscv-mcu/riscv-openocd/blob/a36feb7689b800b923dbfd8c30813382617ad3a9/src/jtag/core.c#L1078-L1079
 # > if(idcode == 0x1000563d) /* correct bumblebee processor idcode */
# >         idcode = 0x1e200a6d;

-- 
Ein Terakawa <applause@elfmimi.jp>


_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel


[prev in list] [next in list] [prev in thread] [next in thread]