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

List:       openocd-development
Subject:    Re: [OpenOCD-devel] [OpenOCD-user] TMS570: corrupted memory access
From:       Andreas Fritiofson <andreas.fritiofson () gmail ! com>
Date:       2014-01-31 13:16:33
Message-ID: CAKGHftciUy82j4vSCgtA4Pz65fCtZwV=8VkTzCtkyP4d1-NtUg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Fri, Jan 31, 2014 at 1:38 PM, Alex Z=FCpke <alexander.zuepke@hs-rm.de>wr=
ote:

>
> I have a TI TMS570 / ARM Cortex R4 and troubles on byte and half-word
> accesses on the flash and SRAM area from the debug interface.
>


> > I followed the read implementation down to arm_adi_v5.c/mem_ap_read(),
> > and it seems that the data read from the DAP port is already corrupted.
>
> Could this be a limitation of the debug interface on the Cortex R4 core
> that it only supports 32-bit accesses via the debug port?
>
>
I recently rewrote the MEM-AP access functions (i.e. mem_ap_read) to match
the ADIv5 spec regarding mapping of DAP register value to memory byte lane.
It works properly on at least ARMv7-M and I guess some ARMv7-A has been
tested too. I don't know about ARMv7-R and definitely not BE target. It
might be some optional feature in ADIv5 that is assumed by the code but not
implemented in your chip (even non-32 bit access is optional IIRC). If
that's the case, I'd consider it a bug because the target should be probed
for the available capabilities and the algorithm adapted accordingly.

First, are you sure you're reading through the MEM-AP and not using APB-AP
access? Because the latter *is* buggy, does not support byte/halfword
access and has endianness issues.

/Andreas

[Attachment #5 (text/html)]

<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 31, \
2014 at 1:38 PM, Alex Züpke <span dir="ltr">&lt;<a \
href="mailto:alexander.zuepke@hs-rm.de" \
target="_blank">alexander.zuepke@hs-rm.de</a>&gt;</span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><br> I have a TI TMS570 / ARM Cortex R4 and troubles on byte \
and half-word<br> accesses on the flash and SRAM area from the debug interface.<br>
</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> &gt; I followed the read \
implementation down to arm_adi_v5.c/mem_ap_read(),<br> &gt; and it seems that the \
data read from the DAP port is already corrupted.<br> <br>
Could this be a limitation of the debug interface on the Cortex R4 core<br>
that it only supports 32-bit accesses via the debug port?<br>
<br></blockquote><div><br></div><div>I recently rewrote the MEM-AP access functions \
(i.e. mem_ap_read) to match the ADIv5 spec regarding mapping of DAP register value to \
memory byte lane. It works properly on at least ARMv7-M and I guess some ARMv7-A has \
been tested too. I don&#39;t know about ARMv7-R and definitely not BE target. It \
might be some optional feature in ADIv5 that is assumed by the code but not \
implemented in your chip (even non-32 bit access is optional IIRC). If that&#39;s the \
case, I&#39;d consider it a bug because the target should be probed for the available \
capabilities and the algorithm adapted accordingly.</div> <div><br></div><div>First, \
are you sure you&#39;re reading through the MEM-AP and not using APB-AP access? \
Because the latter *is* buggy, does not support byte/halfword access and has \
endianness issues.</div><div><br></div> \
<div>/Andreas</div><div><br></div></div></div></div>



------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk

_______________________________________________
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]