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.

SPI DMA timing

Hi

I'm using the Logic EVM with C6748 SOM and I'm investigating spi transfer. So far, I have spi working in dma mode. However, like a few others  on this forum, I've noticed that there is quite a big delay between chip select and start of spi clock if CSHOLD is set. This delay is not present if CSHOLD is not set. Here are two screenshots to illustrate this. Note that I did not specify any delays (wDelay, c2TDelay and t2Cdelay are all 0).

 

If CSHOLD is not set:

 

If CSHOLD is set:

Note that there suddenly is 52.9 us delay between CS going low and the start of clock, and 39.5 us between stopping the clock and CS going high. This is a lot compared to the 2.2 us it takes to actually transfer the two bytes in this experiment.

To track this delay down, I've started hacking the spi edma driver (Spi_edma.c) and inserting gpio low/high transitions on some critical points in Spi_localEdmaTransfer(). What I've noticed is:

  1. if CSHOLD is not set, the spi transfer seems faster, but is in fact not. There is no (or hardly any) delay between CS going low (/high) at the start (/end) of the clock, but there is approximally 48 us delay between entering Spi_localEdmaTransfer() and actually pulling CS low and again a delay between pulling CS high and leaving this function.
  2. most of the delays are caused by the EDMA3 function calls: EDMA3_DRV_getPaRAM() consumes 10 - 13 us, EDMA3_DRV_setPaRAM() consumes 8 - 10 us and EDMA3_DRV_enableTransfer() consumes 2 - 5 us. Since all those functions are called twice (once for transmit and once for receive), this is a penalty of ~ 46 us (oddly enough, the second time these functions are called, they are typically faster than the first time).

I have not investigated why the EDMA3 calls take such a relatively long time (that would be just a little too much in depth for today). I did however hack the spi driver and extended the Spi_DataParam struct with a Uint8 skipConfig field. I also replaced the paramSet struct in Spi_localEdmaTransfer() with two static structs paramRxSet and paramTxSet. With a little more logic in Spi_localEdmaTransfer(), it now skips the EDMA3_DRV_getPaRAM() calls if skipConfig is set to 1. This results in the following timings:

 

CSHOLD is set:

The CS low to start of clock delay is now 32 us, so approximally 40% faster than before.

I have not investigated the delay between the end of clock and CS high since I do not know where this time is spent.

The main questions I have now are:

  1. Are these delays in EDMA3_DRV_* function calls normal?
  2. And are there any methods to reduce these delays?

Thanks in advance.

Admar

PS: For the record: I have the Logic EVM with C6748 SOM, psp drivers 01_30_00_05, BIOS 5.41.09.34 and edma3_lld_01_10_00_01 (at least, I think it is using that one).

  • I've been investigating this a little more. EDMA3_DRV_setPaRAM() and EDMA3_DRV_getPaRAM() functions look like they should not need much time to complete (since it's just some logic and indexing and not a lot of data processing). They do however call EDMA3_LOG_EVENT() if EDMA3_INSTRUMENTATION_ENABLED is defined, and in the project files for the dma drivers I see that this is defined. So, I suspect now that those log calls consume quite some time.

    I have not yet recompiled the dma projects without this define, since I'm not sure which project I need to recompile (edma3_drv_bios_c6748_sample_lib, edma3_drv_bios_lib, edma3_drv_bios_lib_c674, edma3_drv_bios_c674_XDC, edma3_drv_bios_lib_XDC, edma3_rm_bios_c6748_lib,
    edma3_rm_bios_c6748_sample_lib? All of them?).

    Again: is it normal to consume this time? Is there a way to decrease this time? (Perhaps by rearranging L2 cache? Or disabling logging without recompiling the DMA projects?)

    Admar

  • Admar,

    The EDMA project files support the following Build Options:

    Debug:
    “-g –mo –mv6740” compile options used to build library.

    iDebug:
    “-g –mo –mv6740” compile options used to build library.
    Defines -d"EDMA3_INSTRUMENTATION_ENABLED" to enable Instrumentation in EDMA driver.

    Release:
    “-o2 –mo –mv6740” compile options used to build library.

    iRelease:
    “-o2 –mo –mv6740” compile options used to build library.
    Defines -d"EDMA3_INSTRUMENTATION_ENABLED" to enable Instrumentation in EDMA driver.

    For more details regarding Debug, iDebug, Release, iRelease, please refer to C6748_BIOS_PSP_Userguide.doc provided by the BIOS PSP package(psp drivers 01_30_00_05)

    Hence, if you use Debug/Release binaries the EDMA3_LOG_EVENT() will not be executed since "EDMA3_INSTRUMENTATION_ENABLED" is not enabled.

    For better performance, its always better to use Release mode binaries.

    To cross verify this, you can always take a look into the (edma3_drv_bios_c6748_sample_lib, edma3_drv_bios_lib, edma3_drv_bios_lib_c674, edma3_drv_bios_c674_XDC, edma3_drv_bios_lib_XDC, edma3_rm_bios_c6748_lib, edma3_rm_bios_c6748_sample_lib) respective .pjt files.

    Try using the Release mode binaries and check if you are observing better performance values.

    Please let me know the results.

    I know this is not the complete answer to your question, but still you can try this experiment. In the mean time we will get back to you on the SPI CS hold delay issue.

    Thanks and Regards,

    Raghavendra

  • Admar,

    To disable the EDMA3_LOG_EVENT() in the edma libraries, build the drv and rm libraries with debug or Release modes.
    EDMA3_LOG_EVENT() enabled only in iDebug and iRelease modes.

    In the prebuilt libs *_i.lib (eg. edma3_drv_bios_i.lib) are with EDMA3_INSTRUMENTATION_ENABLED and the other set *.lib (eg. edma3_drv_bios.lib) are not.
    Please check which libs are being used for building your application.

    Regards,
    Prasad