Hi,everyone,
We now met some problems in SPI comm between DM368 and DM6437.In our design,we used the DM6437 for Intelligent Video Analysising and the DM368 for encoding.The DM6437 will report the IVA info to the DM368 frequently.So,for easy comm and simplify the comm protocal,we use the DM6437 as the SPI master while the DM368 as slave.
The DM6437 's Mcbsp1 port is used in SPI master mode to comm with DM368's SPI,and the Mcbsp0 port is conected with a SPI flash.
We use EDMA to serve the mcbsp and SPI port in the 2 processors.
Because the DM368 also need to initiate a SPI transfer for IVA command,we use 2 GPIOs for handshaking in the communication.
The figures below is a complete proces routine for DM368 initiate a SPI transfer.
All the writing and reading operation timing is as the upper figure showing.
For some limitations in DM6437 sillicon errata,we eliminate all the L2SRAM edma in our dm6437 code and the MCBSP buffer is located at the L1DRAM on the DM6437.
The DM368's spi driver is modified based on the original SPI master driver in the ti-davinci linux kernel.
Now,the problem is:
If only let the DM6437 sending IVA info to DM368 while DM368 not initiate a SPI tranfer such as for IVA config or hearbeating,the SPI comm seemed not has any problems.
But if the DM368 frequently initiate a SPI tranfer such as for heartbeating with the DM6437,the spi comm will block very soon.We check the debug info at the moment and find the DM6437 finished sending the BUS grant CMD to DM368 and blocked at checking if the DM368 is ready for writing,but the DM368 not recevied enough bytes so it blocked at CMD rcving ,then all the operation blocked.
We read out the DM368's EDMA params regs served for SPI rcving and found the the A_B_CNT reg show the BCnt is not 0.We setting the EDMA as A sync and the BCNT is setted to be FIXED len before start EDMA .So if the BCNT is not 0,it must mean the EDMA has not finished rcving the FIXED len bytes data.
From the DM6437 side, we can seem the LOG_printf in EDMA event miss error interrupt,but the event missing is not in accord with the DM368 initiating spi transfer.I mean it's not everytime the DM368 initiate a SPI transfer a event miss in DM6437 will rising.It seemed the event miss not caused the EDMA loss data.
1. Pls give me some advice how to debug this issue.What condition can cause the DM368 loss EDMA data?DM368's EDMA event miss? I will check it.
Does the DM368 has the limitaiton in the SPI transfer as the DM6437 errata showing:
2.1.2 Serial Port (McASP, McBSP) Transfers Should be Buffered in Internal Memory
We now use DDR as the SPI buffer in the linux driver.
2. Should we
use the ARM internal ram for it?How to use it?the internal 32K
ram? remapping?
2010-12-15
gxf
