This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[DM36x] SPI with DMA

Hi,

I used SPI to send and receive data between DM368 and DM6435.

Unfortunately, it is found that it uses a lot of CPU usage.

Using DMA could be an answer, but SPI driver supporting DMA was not fully implemented for DM368. (linux version: 2.6.18)

 

I manage to modify driver to enable DMA. But it also has another problem.

If DM368 sends '12 34 56 78', DM6435 receives '00 12 34 56'.

EDMA transmits 4bytes to SPI and SPI also sends 4 bytes successfully.

The problem is its sequence.

For the first time, SPI sends SPIDAT1 which is initialized to 0x0000 in the driver.

After that, EDMA transmits 1 byte to SPIDAT1 and this sequence is repeated four times.

If SPIDAT1 is initialized to 0xFFFF, DM6435 receives 'FF 12 34 56' rather than '00 12 34 56'.

 

I just found the following article.

http://e2e.ti.com/support/microcontrollers/msp43016-bit_ultra-low_power_mcus/f/166/p/19191/74533.aspx#74533

I think that the answer in article will solve my problem.

( initialize SPIDAT1 with the first byte in send buffer and decrease the number of EDMA transmission by one. )

 

My question is...

I want to know another solution.

I've been searching the rescent driver and patch. But, I can't find the above answer in them.

Is there another approach to solve this problem?

Any suggestions are welcome.

 

Best Regards,

Jinkyu Park

  • Hello,

    Recently there was a new SPI driver posted that fixed a bunch of issues with the old driver. Can you try this patch?

    http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-July/019573.html

    Thanks,

    Sekhar

  • Thank you

    Comparing with a new driver, I found a code sending an extra byte, 0x00.

    It works well.

     

    But, I got another problem.

    I made a test program to verify SPI transmission with DMA.

    If I repeat sending a bulk of data (4kbytes), everything is ok.

    Sending a small data (12bytes) repeatedly causes one of the follows.

    - Unbalanced preempt count in irq-handler, timer-handler, softirq-handler and so on

    - Kernel hang

    - Kernal panic

    It seems like that something happens at the begin or end of transmission.

    If it is true, transmitting a bulk of data may cause the same problem even though it doesn't happen so far.

    I have no idea how to start debugging.

    If I add some debugging printk(), the problem would not happen.

    And, usleep() between ioctl() sending 12bytes also hide the problem.

     

    Thanks for any help.

     

    Best Regards,

    Jinkyu Park