|
From: Roman V. <bra...@no...> - 2016-11-17 19:07:43
|
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! |