I have witnessed a DSP reset on the C6457 and I'm trying to eliminate or identify reasons.
The facts:
(1) This is software that has run without modifications for several months.
(2) The hardware is not in development.
(3) There hasn't been any reset events prior to this on the C6457.
(4) We don't implement RapidIO resets, Watchdog resets, or any of the other resets listed in C64x+ Peripheral Information and Electrical Specifications, sprs582b.
(5) This was not a debugging session; (could an emulator invoke a system reset without human intervention?)
(6) The image is booted from our proprietary bootloader. The proprietary bootloader does not perform resets. It is believed the application image was running, as boot time is limited to under 1 second.
-The bootloader configures PLL settings.
-The PSC is controlled in the bootloader (including SRIO PSC bring up).
- The application configures rapid IO for communication
1. Would a processor exception manifest itself into a processor reset on any occasion? Currently, our methodology is to let the processor halt after it has executed, which sits in the abort() loop after storing the registers on the stack. (we don't have this information).
2. Could an emulator cause this if it were not connected through the normal connection process?
3. Are all reset registers protected by some coverage of a special flag or set of operations, to protect resets from occurring "magically" or inadvertently through invalid memory accesses?
4. Please widen this answer to C64x+ family of processors.
Any information you can provide, such as past support cases with unexpected device-resets, is appreciated.
Thank you
Will
