I've narrowed it down (I think) to a multiple bugs in cortex_m3.c. Can
somebody who knows the codebase a little better take a look and verify
if it's an actual bug? Here's what I think is going on.
bug 1) cortex_m3_assert_reset() called cortex_m3_clear_halt(), which
contrary to its name, doesn't clear the halt flag, but instead sets
C_HALT.
bug 2) cortex_m3_poll() does an atomic read on DCB_DHCSR, checks if
the target is resetting, and then calls cortex_m3_endreset_event(),
which should reset the DHCSR to its reset state. Unfortunately, the
atomic read which checks that state is called before endreset_event(),
so when it checks (dcb_dhcsr & S_HALT), it's using the old value of
DHCSR, then halts the target, leaving you right back where you started
(halted).
Making assert_reset() actually clear C_HALT and adding another read in
poll() fixed the problem for me.
Index: cortex_m3.c
===================================================================
--- cortex_m3.c (revision 1411)
+++ cortex_m3.c (working copy)
@@ -444,6 +444,7 @@
prev_target_state = TARGET_RUNNING;
}
+ ahbap_read_system_atomic_u32(swjdp, DCB_DHCSR, &cortex_m3->dcb_dhcsr);
if (cortex_m3->dcb_dhcsr & S_HALT)
{
target->state = TARGET_HALTED;
@@ -725,8 +726,9 @@
if (cortex_m3->dcb_dhcsr & C_MASKINTS)
ahbap_write_system_atomic_u32(swjdp, DCB_DHCSR, DBGKEY
| C_DEBUGEN
| C_HALT);
- cortex_m3_clear_halt(target);
-
+ /* Clear C_HALT */
+ ahbap_write_system_atomic_u32(swjdp, DCB_DHCSR, DBGKEY | C_DEBUGEN);
+
/* Enter debug state on reset, cf. end_reset_event() */
ahbap_write_system_u32(swjdp, DCB_DEMCR, TRCENA | VC_HARDERR |
VC_BUSERR);
}
On Sat, Mar 14, 2009 at 7:30 AM, Perry Hung <[email protected]> wrote:
> Hi there,
>
> openocd 0.10 (release) on a 2.6.27 ubuntu kernel.
>
> I'm having a problem with my target halting just after a reset.
>
> The target is a STM32F103 on an Olimex H103 board, programming it through
> a Olimex ARM-USB-OCD programmer.
>
> Once the target is flashed and reset, it almost immediately halts,
> similar to the problem reported here:
> http://forum.sparkfun.com/viewforum.php?f=18
>
> Here's my output:
>
>>reset run
> JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (Manufacturer: 0x23b,
> Part: 0xba00, Version: 0x3)
> JTAG Tap/device matched
> JTAG tap: stm32.bs tap/device found: 0x16410041 (Manufacturer: 0x020,
> Part: 0x6410, Version: 0x1)
> JTAG Tap/device matched
> target state: halted
> target halted due to target-not-halted, current mode: Thread
> xPSR: 0x21000000 pc: 0x00002ef4
>
> The pc at which it halts is somewhat variable, but always within a
> couple of instructions from 0x2ef4. The reason given for the halt is
> also variable, I've seen "target-not-halted," "breakpoint,"
> "debug-request," and "undefined." Doing a "reset" or a "reset run" doesn't
> seem to make any difference.
>
> A resume from the halt resumes normal execution.
>
> Any ideas?
>
> -perry
>
--
Perry Hung
http://separaterealities.com
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
