Hi Paul.
I'm still only familiarizing myself with the code. I have some understanding of
the SWD "bitstream" basics, which helps a little.
On Fri, 16 Jan 2015 10:49:24 +0300, Paul Fertser wrote:
> On Thu, Jan 15, 2015 at 07:07:55PM +0100, Jens Bauer wrote:
>> Error: Failed to read memory and, additionally, failed to find out where
>
> You're right that the actions are queued, but if something failed, then
> an attempt to read the current contents of the hardware TAR register is
> performed, and if the target can respond at all, it will.
> But if the communication with the target is lost, it's impossible to
> investigate where read failed.
That means I'm not going completely in the wrong direction. ;)
Could a 'hint' (last action attempt) be attached to a queue element ?
-Then it would be possible to 'guess' what went wrong, in case the above fails.
---8<-----8<-----8<-----
Info : clock speed 500 kHz
Info : SWD IDCODE 0x2ba01477
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : device id = 0x20016419 [1133]
Error: Failed to read memory and, additionally, failed to find out where
[1141]
Warn : STM32 flash size failed, probe inaccurate - assuming 2048k flash
[1143]
Info : flash size = 2048kbytes [1144]
Error: Failed to read memory and, additionally, failed to find out where
[1149]
stm32f2x failed to read options [1151]
--->8----->8----->8-----
-Repeating the line with -d3 gives some details; in particular, I find 1142
interesting:
---8<-----8<-----8<-----
Info : 1133 1856 stm32f2x.c:768 stm32x_probe(): device id = 0x20016419
Debug: 1134 1856 ftdi.c:949 ftdi_swd_run_queue(): Executing 4 queued
transactions
Debug: 1135 1857 ftdi.c:981 ftdi_swd_run_queue(): OK AP write reg 4 = 1fff7a22
Debug: 1136 1857 ftdi.c:981 ftdi_swd_run_queue(): OK AP write reg 0 = a2000011
Debug: 1137 1857 ftdi.c:981 ftdi_swd_run_queue(): OK AP read reg C = 20016419
Debug: 1138 1857 ftdi.c:981 ftdi_swd_run_queue(): JUNK DP read reg C = ffffffff
Debug: 1139 1857 ftdi.c:949 ftdi_swd_run_queue(): Executing 3 queued
transactions
Debug: 1140 1857 ftdi.c:981 ftdi_swd_run_queue(): JUNK DP write reg 0 = 0000001e
Error: 1141 1857 arm_adi_v5.c:516 mem_ap_read(): Failed to read memory and,
additionally, failed to find out where
Debug: 1142 1857 target.c:2096 target_read_u16(): address: 0x1fff7a22 failed
Warn : 1143 1857 stm32f2x.c:798 stm32x_probe(): STM32 flash size failed, probe
inaccurate - assuming 2048k flash
Info : 1144 1858 stm32f2x.c:813 stm32x_probe(): flash size = 2048kbytes
Debug: 1145 1858 ftdi.c:949 ftdi_swd_run_queue(): Executing 5 queued
transactions
Debug: 1146 1858 ftdi.c:981 ftdi_swd_run_queue(): JUNK DP write reg 0 = 0000001e
Debug: 1147 1858 ftdi.c:949 ftdi_swd_run_queue(): Executing 3 queued
transactions
Debug: 1148 1859 ftdi.c:981 ftdi_swd_run_queue(): JUNK DP write reg 0 = 0000001e
Error: 1149 1859 arm_adi_v5.c:516 mem_ap_read(): Failed to read memory and,
additionally, failed to find out where
Debug: 1150 1859 target.c:2072 target_read_u32(): address: 0x40023c14 failed
User : 1151 1859 command.c:546 command_print(): stm32f2x failed to read options
--->8----->8----->8-----
[1142] It seems reading a 16-bit word from address 0x1fff7a22 failed, so I
think OpenOCD actually 'knows' the address.
The failing line (stm32f2x:791-792):
/* get flash size from target. */
retval = target_read_u16(target, 0x1FFF7A22, &flash_size_in_kb);
The device is a STM32F427VIT.
-The address and size is correct according to the RM0090, but if I look at the
datasheet for STM32F427/429 (Figure 19),
I've tried to find more information in datasheets on the
STM32F407/STM32F427/STM32F429 about this particular address, bu so far, I have
not been able to confirm whether it's correct/incorrect for these particular
devices.
Love
Jens
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
