ersonal; mso-style-noshow:yes; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Arial; mso-ascii-font-family:Arial; mso-hansi-font-family:Arial; mso-bidi-font-family:Arial; color:navy;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page
ection1;} /* List Definitions */ @list l0 {mso-list-id:1264613104; mso-list-type:hybrid; mso-list-template-ids:2049337404 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->
I can think of a few things that might cause the CPU to appear to lock up. (ESD is not one).
1) Make sure that the Bus Timeout timer is set correctly (should be from reset).
2) Make sure that there is a service routine that either resets the devices or pulls the stack frame from the stack.
3) Turn off BDM mode. This will eliminate the BKPT as an issue.
4) Make Very sure that the test pin is grounded! This is the only thing that will kill the CPU.
5) Check for good strong up/downs on CLKMOD pins.
6) Implement a watch dog timer.
7) Fill all unused memory with a trapf instruction and of course have the vector and recovery routine. This will regain control if the CPU fast than an illegal op code.
Message Edited by DrSeuss on
2009-02-05 09:54 PM