On 04/11/2010 21:35, Andreas Fritiofson wrote:
On Wed, Nov 3, 2010 at 10:01 AM, Chris Jones<ch...@martin-jones.com>
wrote:
I tried the IAR software but don't have a JTAG dongle directly
compatible with it. I tried to get it to talk to OpenOCD via GDB
but attempting to download the code to the STM32 that way just
resulted in streams of errors. I didn't spend any more time on this
because I don't think it would help to isolate the issue into or
out of OpenOCD.
There seem to be some circumstances in which attempting to start
OpenOCD connected to an STM32 in stop mode, or switching rapidly
into and out of stop mode, breaks the STM32's debug unit. It's
consistently repeatable. For now we can work around it by being
extremely careful when we try to connect OpenOCD, but I'd like to
try and help prevent the problem.
I agree with Michel that the first step towards that is probably to
determine whether the problem has a reasonable chance of being
fixable in OpenOCD. Otherwise it's a waste of time trying to. We
could try completely different tools to see if they have the same
problem. We can also ask ST (having tried different tools would help
here, too). Maybe someone on the list has the tools and the time
required. Unfortunately, I have neither right now.
I've now spent some more time looking at this problem and have been
digging around in arm_adi_v5.c to see what's going on.
In the fault condition, even the first few operations in
ahbap_debugport_init() don't seem to work. For example, reading the
DP_CTRL_STAT register always returns 0. There's a loop which waits for
the CDBGPWRUPACK bit in that register to be set. It never gets set in
the fault condition, but the loop exits anyway and execution continues.
I think this is a bug, but it doesn't affect the fault other than not
reporting it.
There is an ABORT instruction in a special DR register (*not* one of the
DPACC registers) which looks useful in potentially returning the debug
unit to a sane state, or at least cancelling any outstanding debug
transactions, but until I've got my head around how to make the
necessary JTAG operation I can't get it to do anything.
I wanted to add some more basic tests of DR register reads other than
the DPACC registers to check what was going on, and thought the IDCODE
DR register would be a good start. I added:
adi_jtag_dp_scan_u32(swjdp, JTAG_DP_IDCODE, DP_IDCODE, DPAP_READ, 0,
&dummy, &ack);
LOG_DEBUG("ahbap_debugport_init(): idcode=0x%" PRIx32, dummy);
but this seems to return 0x16 in dummy, which is nothing like the IDCODE
in the ARM/ST documentation (0x3BA00477). This happens on 'working'
STM32s and in the fault condition. Am I doing something daft?
Can some kind soul help me navigate the various functions, please? I'm
happy to spend the time investigating what's going on when armed with
the necessary knowledge.
Chris
--
Chris Jones - ch...@martin-jones.com
Martin-Jones Technology Ltd
148 Catharine Street, Cambridge, CB1 3AR, UK
Phone +44 (0) 1223 655611 Fax +44 (0) 870 112 3908
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
