imi415
/
openocd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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
This commit is contained in:
oharboe 2009-08-19 06:30:08 +00:00
parent 69dd81dcf8
commit 57578b4ea3
1 changed files with 39 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
src/target/cortex_m3.c
View File

@ -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);
}