I am restating a problem in a previous post, hoping to provide additional detail that might help.
Our design is configured to work in Host Boot mode, where the DSP has been released from reset, and is "stalled" while the CPU excercises the the DSP Internal Memory, then loads the code into it.
- PCI_EN is pulled high with 1k resistor
- The IO before Core eratta cannot be implemented because the pad is not accessbile externally in our design. This would be an expensive endeavor and I need to know for certain if not implemting this the cause of my problems.
- All other known PCI-RELATED eratta have been considered
- L2 CACHE configured for ALL to be SRAM
- DSP set to access internal RAM
The problem we see is that during the writes into the DSP internal memory, we sometimes see the PCI bus hang up. We know the process works, as this probem is mostly intermittant in nature.
It is during a PCI memory write to the DSP, that the DSP stops issuing TRDY, and remains in that "Target Retry" state forever.
Some observations:
- The last sucessful memory write has been verified via the JTAG interface to the DSP internal memory using Code Composer to examine memory.
- Sometimes, some of the data does not make it to the inernal memory.
- Resetting the DSP (via Code Composer CPU RESET) will free up the "hanged" bus and the CPU will continue on loading the memory (except for the failed memory write, all remaining memory will be correctly filled).
Here are some snaps of the bus up to the hang:
There are 2 transactions above, the 1st is the last good one, and the 2nd is the 1st bad one.
1st: Gpp starts the “Single Beat Read” by asserting FRAME#. 1 cycle later, Gpp asserts IRDY#. Gpp waits for DEVSEL# from the DSP. Gpp WAITS until TRDY# is asserted from the DSP, at which time the data is valid. After the completion of the data phase, the Gpp deasserts IRDY#, and the DSP releases DEVSEL# and TRDY#.
2nd: This is the failure condition. Gpp starts the “Single Beat Write” as above by asserting FRAME#. 1 cycle later, Gpp asserts IRDY#. Gpp waits for DEVSEL# and TRDY# from the DSP as above (but this time, they are asserted immediately), at which time the data is valid. After completion of the Data Phase, the Gpp deassert the IRDY#, but the DSP never releases DEVSEL# and TRDY#.
- DSP is ready too soon (unlike all the previous transactions).
- DSP never goes “unready” after completion of the data phase.
