Query Regarding DM642

Have you taken a look at the silicon errata for DM642? There are a few advisories for both cache and PCI that may have had some impact in your issues.

Vallabha said:

1) Cache Invalidation did not work after a EDMA transfer

This is not something I have heard of, the closest I am aware of is the L1P incorrectly updating the L1P tag ram, but this could only impact code, not data. When you say cache invalidation would not work after an EDMA transfer could you provide some more specifics such as how you are performing the invalidate, and the sequence of events that leads you to the conclusion that the invalidate failed?

Vallabha said:

2) The PCI bus used to get locked

There are a few PCI errata that might be of interest, though when you say the PCI bus would lock there is not much detail to analyze. What sort of sequence did you go through to get the PCI bus to lock up, and what does a locked state consist of, just no response on the host PCI device? The first thing that comes to mind for this would be configuring the PCI to access some location within the DM642 that is not valid, so the PCI peripheral gets stuck waiting for the invalid memory, though this is just conjecture.

Bernie Thompson said:

This is not something I have heard of, the closest I am aware of is the L1P incorrectly updating the L1P tag ram, but this could only impact code, not data. When you say cache invalidation would not work after an EDMA transfer could you provide some more specifics such as how you are performing the invalidate, and the sequence of events that leads you to the conclusion that the invalidate failed?

Well let me correct myself first here. The "Cache inavlaidation was done before the EDMA"

Scenario: I have a ring buffer. I copy certain amount of data everytime into this buffer. At the buffer boundary if I find that the incoming length of data is higher than the empty bytes left in the buffer, then I copy the remaining data (via EDMA) to the top of the buffer and continue copying the new data. I do some kind of decoding on this data.

My decoding was fine till I reach the buffer boundary. As soon I reach the buffer boundary, and I decode the next set of data after a EDMA, the decoder always returned with an error although all the parameters were right. To check if the data was right, I increased the ring buffer length and the data decoded was more but again failed at the above condition of buffer boudary.

So experimentally I did a memset to the memory section instead of a cache invalidation before EDMA was triggered and the code worked fine. Hence my assumption that somehow the cache inv failed.

I used the following command to inv cache

CACHE_wbInvL2((void *)dst, cnt*4, CACHE_WAIT);

Bernie Thompson said:

There are a few PCI errata that might be of interest, though when you say the PCI bus would lock there is not much detail to analyze. What sort of sequence did you go through to get the PCI bus to lock up, and what does a locked state consist of, just no response on the host PCI device? The first thing that comes to mind for this would be configuring the PCI to access some location within the DM642 that is not valid, so the PCI peripheral gets stuck waiting for the invalid memory, though this is just conjecture.

In my sys there is a master proc and DM642 is a slave. Master gets resetted if something (I do not know what) goes wrong on the pci interface. As the system was getting resetted constantly I assume something going wrong on the PCI bus. As I do not have an access to PCI bus analyzer I do not know what went wrong. So I would like to know if there are certain things which could lock the PCI bus then I would try to relate them to my sys and would have an better idea as to what can be fixed to avoid this.