summaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorDavid Brownell <dbrownell@users.sourceforge.net>2010-01-27 13:47:48 -0800
committerDavid Brownell <dbrownell@users.sourceforge.net>2010-01-27 13:47:48 -0800
commit3172be80a3e14f4c8c3628a37db348c04fd60fc4 (patch)
tree17920235e9f192ca945e3a024d7ef78f09a6564d /src
parentd44f1aaeff45d26348826bdff07caf3d097eca15 (diff)
downloadopenocd_libswd-3172be80a3e14f4c8c3628a37db348c04fd60fc4.tar.gz
openocd_libswd-3172be80a3e14f4c8c3628a37db348c04fd60fc4.tar.bz2
openocd_libswd-3172be80a3e14f4c8c3628a37db348c04fd60fc4.tar.xz
openocd_libswd-3172be80a3e14f4c8c3628a37db348c04fd60fc4.zip
Cortex-M3: report lockup, and recover
ARMv7-M defines a "lockup" state that's entered in certain double fault sequences which can't be recovered from without external help. OpenOCD has previously ignored this. Issue a diagnostic saying the chip has locked up, and force exit from this state by halting the core. It's not clear this is the best way to handle lockup; but there should now be less confusion. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Diffstat (limited to 'src')
-rw-r--r--src/target/cortex_m3.c15
1 files changed, 15 insertions, 0 deletions
diff --git a/src/target/cortex_m3.c b/src/target/cortex_m3.c
index adce4d9c..3bbe42c9 100644
--- a/src/target/cortex_m3.c
+++ b/src/target/cortex_m3.c
@@ -416,6 +416,21 @@ static int cortex_m3_poll(struct target *target)
return retval;
}
+ /* Recover from lockup. See ARMv7-M architecture spec,
+ * section B1.5.15 "Unrecoverable exception cases".
+ *
+ * REVISIT Is there a better way to report and handle this?
+ */
+ if (cortex_m3->dcb_dhcsr & S_LOCKUP) {
+ LOG_WARNING("%s -- clearing lockup after double fault",
+ target_name(target));
+ cortex_m3_write_debug_halt_mask(target, C_HALT, 0);
+ target->debug_reason = DBG_REASON_DBGRQ;
+
+ /* refresh status bits */
+ mem_ap_read_atomic_u32(swjdp, DCB_DHCSR, &cortex_m3->dcb_dhcsr);
+ }
+
if (cortex_m3->dcb_dhcsr & S_RESET_ST)
{
/* check if still in reset */