David Brownell <david-b@pacbell.net> Clean up some Cortex-M3 reset handling.

 - AIRCR_SYSRESETREQ is generic; use it on any system where
  SRST won't fly, not just on Stellaris-based ones.

 - Reformat and improve comments about the Stellaris quirk; and
  xref the only public docs (an email) about the issue.

It seems that *most* Stellaris chips have this problem.  Tempest
parts aren't yet in general sampling; and if rev B silicon for
earlier chips exists, it's not very visible yet.

git-svn-id: svn://svn.berlios.de/openocd/trunk@2595 b42882b7-edfa-0310-969c-e2dbd0fdcd60

1 files changed, 39 insertions, 17 deletions

diff --git a/src/target/cortex_m3.c b/src/target/cortex_m3.c
index 62615743..ea20dfd1 100644
--- a/src/target/cortex_m3.c
+++ b/src/target/cortex_m3.c
@@ -760,11 +760,14 @@ int cortex_m3_assert_reset(target_t *target)
 		target_state_name(target));
 
 	enum reset_types jtag_reset_config = jtag_get_reset_config();
+
+	/*
+	 * We can reset Cortex-M3 targets using just the NVIC without
+	 * requiring SRST, getting a SoC reset (or a core-only reset)
+	 * instead of a system reset.
+	 */
 	if (!(jtag_reset_config & RESET_HAS_SRST))
-	{
-		LOG_ERROR("Can't assert SRST");
-		return ERROR_FAIL;
-	}
+		assert_srst = 0;
 
 	/* Enable debug requests */
 	mem_ap_read_atomic_u32(swjdp, DCB_DHCSR, &cortex_m3->dcb_dhcsr);
@@ -794,15 +797,21 @@ int cortex_m3_assert_reset(target_t *target)
 		mem_ap_write_atomic_u32(swjdp, DCB_DEMCR, TRCENA | VC_HARDERR | VC_BUSERR | VC_CORERESET);
 	}
 
-	/* following hack is to handle luminary reset
-	 * when srst is asserted the luminary device seesm to also clear the debug registers
-	 * which does not match the armv7 debug TRM */
-
+	/*
+	 * When nRST is asserted on most Stellaris devices, it clears some of
+	 * the debug state.  The ARMv7M and Cortex-M3 TRMs say that's wrong;
+	 * and OpenOCD depends on those TRMs.  So we won't use SRST on those
+	 * chips.  (Only power-on reset should affect debug state, beyond a
+	 * few specified bits; not the chip's nRST input, wired to SRST.)
+	 *
+	 * REVISIT current errata specs don't seem to cover this issue.
+	 * Do we have more details than this email?
+	 *   https://lists.berlios.de/pipermail
+	 *	/openocd-development/2008-August/003065.html
+	 */
 	if (strcmp(target->variant, "lm3s") == 0)
 	{
-		/* get revision of lm3s target, only early silicon has this issue
-		 * Fury Rev B, DustDevil Rev B, Tempest all ok */
-
+		/* Check for silicon revisions with the issue. */
 		uint32_t did0;
 
 		if (target_read_u32(target, 0x400fe000, &did0) == ERROR_OK)
@@ -816,10 +825,16 @@ int cortex_m3_assert_reset(target_t *target)
 
 				case 1:
 				case 3:
-					/* only Fury/DustDevil rev A suffer reset problems */
+					/* Fury and DustDevil rev A have
+					 * this nRST problem.  It should
+					 * be fixed in rev B silicon.
+					 */
 					if (((did0 >> 8) & 0xff) == 0)
 						assert_srst = 0;
 					break;
+				case 4:
+					/* Tempest should be fine. */
+					break;
 			}
 		}
 	}
@@ -838,13 +853,20 @@ int cortex_m3_assert_reset(target_t *target)
 	}
 	else
 	{
-		/* this causes the luminary device to reset using the watchdog */
-		mem_ap_write_atomic_u32(swjdp, NVIC_AIRCR, AIRCR_VECTKEY | AIRCR_SYSRESETREQ);
-		LOG_DEBUG("Using Luminary Reset: SYSRESETREQ");
+		/* Use a standard Cortex-M3 software reset mechanism.
+		 * SYSRESETREQ will reset SoC peripherals outside the
+		 * core, like watchdog timers, if the SoC wires it up
+		 * correctly.  Else VECRESET can reset just the core.
+		 */
+		mem_ap_write_atomic_u32(swjdp, NVIC_AIRCR,
+				AIRCR_VECTKEY | AIRCR_SYSRESETREQ);
+		LOG_DEBUG("Using Cortex-M3 SYSRESETREQ");
 
 		{
-			/* I do not know why this is necessary, but it fixes strange effects
-			 * (step/resume cause a NMI after reset) on LM3S6918 -- Michael Schwingen */
+			/* I do not know why this is necessary, but it
+			 * fixes strange effects (step/resume cause NMI
+			 * after reset) on LM3S6918 -- Michael Schwingen
+			 */
 			uint32_t tmp;
 			mem_ap_read_atomic_u32(swjdp, NVIC_AIRCR, &tmp);
 		}