MEM-AP access through banked data registers MEM_AP_REG_BD0..3
does not increment TAR regardless of the current autoincrement mode.
mem_ap_read_u32() and mem_ap_write_u32() can keep the current
autoincrement mode instead of switching autoincrement off.
Change-Id: Ib7ec688d3e04f1da678363cd2819ce90e8910e58
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4163
Tested-by: jenkins
Reviewed-by: Andreas Bolsch <hyphen0break@gmail.com>
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Problem: If the same memory location is accessed alternatively
by MEM-AP banked data registers without autoincrement and by standard
autoincremented read/write, TAR register is not updated correctly.
How to replicate: On a Cortex-M issue
mdw 0xe000edf0
multiple times. When poll is on (poll reads the same memory location)
only the first read is correct.
0xe000edf0: 01000000
0xe000edf0: 00000000
0xe000edf0: 20002640
0xe000edf0: 01000000
0xe000edf0: 00000000
0xe000edf0: 00000000
No problems with poll off.
0xe000edf0: 01000000
0xe000edf0: 01000000
0xe000edf0: 01000000
mem_ap_setup_tar() writes to MEM_AP_REG_TAR if requested TAR value
changed or CSW_ADDRINC_... is currently active.
However if an autoincremented access has been issued and autoinc
switched off in CSW afterwards, TAR does not get updated.
The change introduces mem_ap_update_tar_cache() which is called
after queuing of any access to MEM_AP_REG_DRW. It simulates
TAR increment to keep tar_value in sync with MEM_AP.
Crossing tar autoincrement block boundary invalidates cached value.
mem_ap_write() and mem_ap_read() do not check tar autoincrement
block boundary, mem_ap_setup_tar() is called before each transfer instead.
dap_invalidate_cache() is introduced to ensure invalidation
of all cached values during dap_dp_init() and swd_connect()
Change-Id: I815c2283d2989cffd6ea9a4100ce2f29dc3fb7b4
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4162
Tested-by: jenkins
Reviewed-by: Christopher Head <chead@zaber.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
This avoids trying to read memory from the wrong hart, if the current
hart was changed by an earlier call (eg. to poll()).
Change-Id: I73da1e01c8d01d68f01ac7fdd6c548380a70cfd3
The existing code only used Memory Access mode to read memory,
which uses 32 bit operations only.
Rework the code to check the alignment/size of the read/write operation,
and use the Memory Access mode to read aligned 32 bit memory.
When using unaligned access, or 8 or 16 bit reads, use LDR{BHW} and STR{BHW}
instead.
The exception handling is still the same as it was before (meaning it breaks
when things go wrong), but I can now read an 8 bit register correctly.
Change-Id: I739a5ee825c0226ed4a89c32895cc2a047b8dc15
Signed-off-by: Bas Vermeulen <bas@daedalean.ai>
Reviewed-on: http://openocd.zylin.com/4301
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <matthias@welwarsky.de>
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Commit ef02b69b14 included
a call to cmsis_dap_cmd_DAP_Connect() before calling
cmsis_dap_cmd_DAP_SWJ_Sequence(). According to comment
it is necessary for at least Keil ULINK-ME.
Commit 72c3464be4 added
a cmsis_dap_cmd_DAP_Disconnect() before connect call to pair
connection/disconnection. It solves some problems on Atmel EDBG.
Unfortunately calling either of cmsis_dap_cmd_DAP_Connect()
or cmsis_dap_cmd_DAP_Disconnect() deasserts reset signal.
So these workarounds break ability to connect under reset.
Use cmsis_dap_cmd_DAP_Disconnect() and cmsis_dap_cmd_DAP_Connect()
pair only if both SRST and TRST are deasserted.
Change-Id: I0914dae0a1360b8c7fe48231ff3867caedfb2dbe
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reported-by: Leonardo Sabino dos Santos <leonardo.sabino@gmail.com>
Reviewed-on: http://openocd.zylin.com/4100
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
As part of this I improved the memory read/write fatal error handling a
bit. Now at least we try to leave autoexec turned off, and will even
restore the temp registers if the situation isn't too hosed for that.
Partly addresses Issue #142
Change-Id: I79fe3f862f11c6d20441f39162423357e73a40c1