We've been working on a very tough problem over the last few days. We're running applications on both the DSP and ARM9 with shared memory communication. The application will crash after between 10 minutes to 1+ hrs. When the crash occurs, the DSP will be held in reset and the ARM9 will be stuck on the data access error interrupt. The bizarre thing we're seeing is that our proprietary bootloader appears to have been loaded into shared RAM by the TI ROM bootloader. The ARM9 MMU translation table is in the shared ram that gets hit. We're monitoring the reset input pin and it is not causing the issue. We also verifed timer1, which can be configured as a watchdog if corrupted is in tact, all zeroed out because it's not used. Any ideas of what else could cause the ROM bootloader to run without reset toggle? Also, all ARM9 processor registers appear to be in tact, eliminating external triggered reset as the cause.
At this point we're not even sure which core is the initial trigger, or if it is a software sourced problem. We're adding monitoring of the input voltages to see if there's any transient noise present when the problem occurs.
Any ideas would be greatly appreciated.
Thanks,
Jim