• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 644 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

OMAPL138 SPI DMA Problem

John Wilkes
Expert 1315 points
Other Parts Discussed in Thread: OMAP-L138

Hello,

I have an application that runs on the DSP side of an L138, it uses the DMA to read data from the SPI1 peripheral. When this application is run standalone (loaded and run via JTAG) it works fine and will run all day long. However, when the application is loaded from the ARM running Arago Linux using DSP/LINK, the data transmission stops. Upon investigation, it seems that the DMAREQEN bit in the SPI1 SPIINT0 register is periodically being reset, causing DMA transfers from the port to cease. I am fairly certain that there is nothing in the DSP side code that is doing this so it must be the ARM. I notice that when Linux boots, amongst the LBG (Linux Booting Garbage) that gets spewed out of the debug port are the lines (they do not appear together):

spi_davinci spi_davinci.1: DaVinci SPI driver in EDMA mode

m25p80 spi1.0: m25p64 (8192 Kbytes)

spi_davinci spi_davinci.1: Controller at 0xfef0e000

Does this imply that there is some code in Linux trying to do something with the SPI1 port and is this the culprit that resets the DMAREQEN bit? If so, how do I stop it? If not, what else could be causing this problem.

Cheers,

John.

  • 0
    Guru 26430 points

    The kernel source for the OMAP-L138 EVM does seem to access the SPI1 port. Appears to talk to some SPI flash. See

    arch/arm/mach-davinci/board-da850-evm.c

    TI did not provide any easy kernel config to remove the SPI flash code. You'll have to comment it out line by line yourself. Are you using the SPI flash for bootloaders, kernel or file system? Surprised a conflict did not come up before. Custom board?

  • 0 in reply to Norman Wong
    Expert 1315 points

    Hi Norman,

    Thanks for your reply. It is a custom board that uses the SPI1 port of the device. However, this board is based upon a LogicPD SOM so it also uses SPI1 to boot from a serial flash, but this is used by uboot only. With the help of a colleague, I found the answer to this myself:

    TI do provide a kernel config utility in the DVDSK (make linux_config). This allows the SPI support to be removed and the kernel can be rebuilt and the problem goes away.

    OK, but I have now hit another problem which is sort of related. My DSP application uses the UART1 perhiperal and, in a similar way to the SPI1 port, Linux loads up drivers for this UART and prevents the DSP from using it. I cannot simply disable all UART support from the linux Kernel (as I did for SPI) because Linux uses UART 2 for the debug terminal port.

    So my question is this: how can I stop Linux using UART1 while still allowing it access to UART2 for the debug console?

    Cheers,

    John.

  • 0 in reply to John Wilkes
    Guru 26430 points

    I'll' have to try linux_config. I think it's not in the version that I'm using. DVSDK 03.21. The console is defined in the bootargs passed down from U-Boot. You have to change ttyS1 to ttyS2 or ttyO1 to ttyO2 depending on your kernel version. UART2 will need to be manually pinmuxed in the kernel board init file. I believe the kernel will still init every serial port. In my L137 code, it's just a bitmask. Not sure in yours. People on this forum have moved the Linux console. Search around here or at TI's Wiki http://processors.wiki.ti.com.

  • 0 in reply to Norman Wong
    Expert 1315 points

    Hi Norman,

    Thanks for your reply: yes it turns out that the bit mask is set in 'arch/arm/mach-davinci/board-da850-evm.c' and can be edited to only use UART2. I also needed to use the config tool to tell the kernel to only load one serial driver. There were a couple of other changes needed but eventually I could get Linux to relinquish control of UART1. However, my DSP code still would not communicate. The problem turned out to be down to the CTS line being MUXed with a McASP pin. I have posted separately about this:

    http://e2e.ti.com/support/dsp/integra_dsparm/f/625/p/148009/535082.aspx#535082

    Thanks again for your help. With the exception that I cannot use the McASP from Linux (not a big problem to me), my application is now working.

    Cheers,

    John.

  • 0
    Prodigy 205 points

    Dear John,

    i am starting developing a SPI driver with DMA for accessing a peripheral (ADC) that runs on the DSP side of an OMAP L138.

    Would you please share your application run in standalone?

    Best

    DA