This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

After going hot DSP has no clock.

It would not accept the SM320F28335PTPMEP part number:  We have had two devices lock up (no clock) recently while doing temperature cycles, it happened while going hot both times.  We are using a 20MHz crystal and when it fails there is no signal on X1 or X2 at all and we cannot connect to JTAG.  We repaired one by replacing DSP recently but now a 2nd one failed with same symptoms.  Power is good.  We have been using this crystal for years now without issues, we have recently updated PLL to 80MHz following the guidelines and it has worked fine at room temp and some units have passed temperature tests fine.  Once unit fails it never recovers, cannot load code since JTAG and debugger does not connect. I have XCLKIN tied to ground and /RST line is high and crystal is good.  I have not changed the DSP for 2nd failure yet.

Is there anyway that code could have gone into a state where external crystal was never activated again? 

With one failure, a bad DSP may be the cause but with 2 something else is likely wrong.  It appears to be a hardware issue but this design has been used for years now and this has not happen before.  I can send the bad DSP and change this one if no other ideas.    

     

    

  • You mention you were able to repair the first board by changing the DSP. It does point to the device gone bad (since the crystal and load caps were not changed and the board started working after the DSP replacement). 

    Is there any way that code could have gone into a state where external crystal was never activated again? 

    Yes, this can happen if the device is put into HALT mode, which would shut down the (internal) crystal oscillator. Does your code contain a function that would put the device in HALT mode?

  • I had asked firmware to be sure it was never "accidentally" going into that mode, it should never be.  

    Even if it did go into HALT mode, is there a way to get it out? (it will not connect to debugger in this state)  

  • But does your code have a HALT routine? That is a very important question to answer. Even if there is, I agree control shouldn't go there, under normal circumstances. But then, we are dealing with a normal circumstance.

    Even if it did go into HALT mode, is there a way to get it out? (it will not connect to debugger in this state) 

    Answer to this question depends on your answer to my previous question (whether code contains a HALT routine)