CCS/TMS320F28335: F28335 Freezes during boot

PS.
Sorry the error is only this:
Error connecting to the target: Error 0x80000206/-1156 Fatal Error during: Memory, Register, OCS, Lost processor clock. Device may be operating in a low-power mode. Do you want to bring it out of this mode?

Nikola,

 

What kind of clock source do you have in your design? Is it a external “can” oscillator (with its own power–supply) that outputs a clock of its own or is it a quartz crystal/ceramic resonator that works in conjunction with the on-chip oscillator?

 

If it is the latter (crystal/resonator), could you please check X1 or X2 pin with an oscilloscope to check if the oscillations are present when you see this problem?

 

Do you have one or more of the low-power modes (IDLE, STANDBY & HALT) in your code? Is there a possibility that a low-power mode is getting invoked (specifically STANDBY or HALT)?

 

Is there a chance that your power-supply “current-starves” the core? I especially have this suspicion, since you say it happens upon boot. If the power-supply stage is not architected correctly, it is possible that the supply is unable to meet the in-rush current demand and puts the device in some unknown state. Can you try with an alternate power-supply (like a benchtop lab power supply)?

Also, how frequently does this happen? Please provide a specific number (like "n" out of 100 power-up attempts)

Hi Hareesh,

thank you for your swift response! Well this occurs, once in 20 power-ups. I use a "Can" oscillator, and it remains stable when this phenomenon occurs, (normal 30 MHz clock). Also I have re-checked MCLKSTS bit of the PLLSTS register and it is still zero after a debugger reset and after /XRS reset.

About low power modes, I don't use them, nor do I temper with respective registers during application run. Is it possible for a processor to go low power on it's own or even to reset due faulty instruction interpretation, or some XINTF erronous read (I use external static RAM to place some of the data)?

Also I have tried multiple different power supplies and the event occurs with the same frequency. I will check the regulator circuits for voltage drops during the events and see if I can find anything.

Thank you very much,
and kind regards
Nikola

No, the device cannot go into LPM "on its own". LPMCR0 is EALLOW protected. It needs to have the correct value and the IDLE instruction needs to be executed in order to put the device into LPM. Please check the XCLKIN input to verify clock is present when you see this issue.

 

Please configure the PLL (and the XCLKOUT pin) for a specific frequency and check if the XCLKOUT frequency continues to be correct.

 

An "unwanted" reset is possible because of Watchdog counter overflow. Is it disabled in your system? If not, please try disabling it.

 

Likewise, if you use code security, try disabling it.

 

A reset is also possible because of noise.

 

You could also try this: Program a simple GPIO toggling code in flash. See if the problem repeats. You could even create a trap for accidental resets. i.e. tie a GPIO pin to a particular level during power-up. Code will loop until the GPIO pin flips state. Once this happens, you could catch accidental resets. This experiment would take any code dependency out of the picture.