[OpenOCD-user] JLink and RTL8710 SWD reset issues

[Roman V. <bra...@no...>]

Hello OpenOCD,

After successfully re-flashing a Realtek 8170 several times without
issues via the following setup (SEGGER JLINK via SWD):

https://bitbucket.org/rebane/rtl8710_openocd/pull-requests/1/add-support-for-osx-with-preinstalled/diff#comment-25650541

I ended up flashing too early in the target's memory map, where the
state of the chip is not as stable (bootloader1 instead of
bootloader2). Then I started getting the following errors from my
previously working OpenOCD setup:

--------------
Debug: 278 5121 jlink.c:1895 jlink_swd_switch_seq(): JTAG-to-SWD
Debug: 279 5121 jlink.c:1919 jlink_swd_run_queue(): Executing 2 queued
transactions.
Debug: 280 5121 jlink.c:530 jaylink_log_handler(): Starting write /
read operation (length = 60 / 29 bytes).
Debug: 281 5121 jlink.c:530 jaylink_log_handler(): Wrote 4 bytes into buffer.
Debug: 282 5121 jlink.c:530 jaylink_log_handler(): Wrote 28 bytes into buffer.
Debug: 283 5121 jlink.c:530 jaylink_log_handler(): Buffer filled up
with 28 bytes.
Debug: 284 5122 jlink.c:530 jaylink_log_handler(): Sent 60 bytes to device.
Debug: 285 5122 jlink.c:530 jaylink_log_handler(): Received 29 bytes
from device.
Debug: 286 5122 jlink.c:530 jaylink_log_handler(): Read 28 bytes from buffer.
Debug: 287 5122 jlink.c:530 jaylink_log_handler(): Read 1 bytes from buffer.
Debug: 288 5122 jlink.c:1944 jlink_swd_run_queue(): SWD ack not OK: 7 JUNK
Debug: 289 5122 command.c:626 run_command(): Command failed with error code -4
User : 290 5123 command.c:687 command_run_line(): in procedure 'init'
in procedure 'ocd_bouncer'
Debug: 291 5123 command.c:626 run_command(): Command failed with error code -4
--------------------


I would rule out signal integrity (cables) issues since the previous
re-flashing via SWD worked flawlessly everytime and I did not change
the arrangement.

In order to validate my assumptions, I fired up a JLINK session where
I successfully reset and halt the chip, allowing me to step and do
everything I used to do with OpenOCD:

====================
$ JLinkExe
SEGGER J-Link Commander V6.10m (Compiled Nov 10 2016 18:38:38)
DLL version V6.10m, compiled Nov 10 2016 18:38:25

Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: ...
License(s): RDI,FlashDL,FlashBP,JFlash,GDB
VTref = 3.300V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: CORTEX-M3
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "CORTEX-M3" selected.


Found SWD-DP with ID 0x2BA01477
SWD speed too high. Reduced from 4000 kHz to 2700 kHz for stability
AP-IDR: 0x24770011, Type: AHB-AP
Found Cortex-M3 r2p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl 0 @ E00FF000
ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB000 SCS
ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl 0 [3]: FFF01000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl 0 [4]: FFF41000, CID: B105900D, PID: 003BB923 TPIU-Lite
ROMTbl 0 [5]: FFF42000, CID: B105900D, PID: 003BB924 ETM-M3
Cortex-M3 identified.
J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
SYSRESETREQ has confused core. Trying to reconnect and use VECTRESET.
Found SWD-DP with ID 0x2BA01477
SWD speed too high. Reduced from 2000 kHz to 1350 kHz for stability
AP-IDR: 0x24770011, Type: AHB-AP
Found Cortex-M3 r2p1, Little endian.
J-Link>halt
PC = 00000100, CycleCnt = 00000000
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
R8 = 00000000, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 00000000
SP(R13)= 1FFFFFFC, MSP= 1FFFFFFC, PSP= 00000000, R14(LR) = FFFFFFFF
XPSR = 01000000: APSR = nzcvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00
J-Link>s
00000100:  DF F8 28 D0        LDR       SP, [PC, #+0x28]
J-Link>s
00000104:  44 F0 1C BD        B         #+0x44A38
J-Link>s
00044B40:  40 F2 00 30        MOVW      R0, #0x300
J-Link>s
00044B44:  40 F6 C8 32        MOVW      R2, #0xBC8
==============


So apparently JLINK software allows for VECTRESET **and** SYSRESETREQ:

"""
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
SYSRESETREQ has confused core. Trying to reconnect and use VECTRESET.
"""

Is it possible to replicate this reset behavior in OpenOCD? From what
I gather in the docs, only one argument is permitted in:

cortex_m reset_config [vectreset|sysresetreq]

When I run OpenOCD, the reset signal does not act on the target like
JLinkExe does.


My current minimal test config file is:

============
$ cat ameba_ocd_test.cfg
set CHIPNAME ameba1
transport select swd
source [find target/swj-dp.tcl]

set _CPUTAPID 0x2ba01477
swj_newdap $CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID

set TARGETNAME $CHIPNAME.cpu
target create $TARGETNAME cortex_m -chain-position $TARGETNAME

adapter_khz 500

targets
cortex_m reset_config vectreset
==============

And I run it via:

openocd -d3 -f interface/jlink.cfg -f ameba_ocd_test.cfg


So any hints on how I can reproduce JLinkExe session/behavior within OpenOCD?

$ openocd -v
Open On-Chip Debugger 0.10.0-dev-00395-g674141e-dirty (2016-10-23-23:20)

Thanks in advance!