• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 637 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.

SK-AM64: MCSPI reduce inter-word delay

Fabio Samparisi
Prodigy 30 points

Part Number: SK-AM64
Other Parts Discussed in Thread: SYSCONFIG

I would like to kindly ask you for some help on the MCSPI module.

I set the MCSPI instance 0 to be a Single Master, 3 Pin Mode, TX only. Therefore, I'm only using channel 0, I enabled the tx FIFO and set the data-width to 32 bits. My clock frequency is 12.5MHz. My goal is to continuously send out data without the need to receive anything. Everything works correctly and I can see on an oscilloscope the generated clock and data signals. My problem is that I always get a little delay between consecutive 32-bit words. I would like to get a continuous stream of bits, without any time-delay between words. Is that possible? I read about TURBO mode and that effectively reduces the delay but it's still not satisfactory. The delay I see is approximately 80ns long, which is coincidentally 1 clock period (1 / 12.5MHz). Is there a way to reduce the inter-word delay even further? I tried also using DMA but it doesn't affect that delay. I hope you could help me to get a clearer picture of what's going on inside the MCSPI module.

Fabio

  • 0
    TI__Guru** 108980 points

    Hello Fabio,

    Which core is driving the MCSPI and what version of SDK is running on that core?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Prodigy 30 points

    I'm driving it with Cortex-R5 0_0 using MCU+ SDK for AM64x version 8.3.0.18

  • 0 in reply to Fabio Samparisi
    TI__Guru** 108980 points

    Hello Fabio,

    Understood. I am reassigning your thread to our MCU+ SDK folks. Please ping the thread if you don't get a response within a couple of business days (though note that Thanksgiving next week may lead to some delayed responses).

    Regards,

    Nick

  • +1 in reply to Nick Saulnier
    TI__Guru 52688 points

    Hello Fabio,

    Can you briefly explain how you continuously transmit data?

    Are you using an API or writing data directly to the register?

    Actually in MCSPI/OTHER IP you put the data in the data register, the MCSPI IP has to read the data from the data register and the next one transfers this data.

    So, I think you can't reduce this time and instead of calling functions you should make sure that you can directly write data in DATA register this way we can remove API branch time. In my view you cannot reduce this inter delay time.

    Can you briefly explain your application ?

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    Prodigy 30 points

    Hi Swargam,

    I took the mcspi_performance_32bit example and adapted it to my needs. This means that, apart from initialization, I never use the API but instead write directly to the MCSPI registers. In my case, I'm using Single Master, 3 Pin Mode, TX only with tx FIFO enabled. The data-width is 32 bits, and the clock frequency is 12.5MHz. In addition, I enabled the TX0_EMPTY interrupt, which is triggered whenever there are AEL (Almost-Empty-Level) bytes in the tx FIFO. In the ISR I take care of inserting exactly AEL bytes into the tx FIFO (by writing directly into the tx register). What I get is a continuous stream of 32-bit words interleaved by a clock-cycle (80ns). This happens with TURBO mode enabled.

    Regards

    Fabio

  • 0 in reply to Fabio Samparisi
    Prodigy 30 points

    Hi Swargam,

    I decided to go with the PRU since it gives me complete control over the timing. Thank you for your help.

    Best regards

    Fabio S.

  • 0 in reply to Fabio Samparisi
    TI__Guru 52688 points

    Hello ,

    I initially suggested to use PRU for your application and later I realized that you need to write assembly code for PRU .So, I have edited my comment .

    Well you can experiment with PRU and raise a new thread if you have any problem.

    I am sharing toggling GPIO pins and reading GPIO pins on PRU and use those examples for your application.

    I have an example code for toggling a GPIO on a PRU and loading the same PRU application from R5F0_0 will share the example code and document by tomorrow.

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    TI__Guru 52688 points

    Hello ,

    Pleas see my answers below.

    Configure GPIO pins from system_config :

    • Inside the empty project, double-click and open example.sysconfig file
    • Go to ‘TI DRIVERS’ section, click the plus symbol to add a ‘PRU(ICSS) instance’.
    • In the created PRU(ICSS) instance, go to ‘Additional ICSS Settings’ and add a new instance for it.
    • In the new instance, namely ‘Additional ICSS Settings 0’, add a new instance for ‘PRU (ICSS) GPIO’
    • Select the PRU instance you want to use (ICSSG0 as instance and PRU_ICSSG0_PRU0 as PRU instance, if you are using ICSS_G0_PRU_0 core in the target configuration)
    • Select the signals you want to enable (GPOx for output mode and GPIx for input mode), the pins get allocated automatically.
    • Press Ctrl+S to save changes in the sysconfig file.

    BASIC GPIO TOGGLE EXAMPLE :

    ; CCS/makefile specific settings
    .retain ; Required for building .out with assembly file
    .retainrefs ; Required for building .out with assembly file

    .global main
    .sect ".text"

    ;***************************** includes *************************************
    .include "icss_constant_defines.inc"
    ; .asg R2, TEMP_REG

    ;********
    ;* MAIN *
    ;********

    main:

    init:

    ; Give the starting address and number of bytes to clear.
    zero &r0, 120

    Keep_toggling:
    ldi R30, 0x2 ; toggles GPIO pin 1
    ldi R30, 0x0
    qba Keep_toggling

     To load PRU binary from R5F0 :

    1. Compile your PRU code and finally you will get pru_load_bin.h file.
    2. Include your pru_load_bin.f file in your R5F0 application. I copied all the buffer values ​​into the Test.h file.
    3. You can add below function in your R5F0 workspace.

    void pru_init()
    {
    int status;


    status = PRUICSS_initMemory(gPruIcss0Handle, PRUICSS_DATARAM(PRUICSS_PRUx));
    DebugP_assert(status != 0);
    status = PRUICSS_resetCore(gPruIcss0Handle, PRUICSS_PRUx);
    DebugP_assert(SystemP_SUCCESS == status);
    status = PRUICSS_disableCore(gPruIcss0Handle, PRUICSS_PRUx);
    DebugP_assert(SystemP_SUCCESS == status);


    status = PRUICSS_writeMemory(gPruIcss0Handle, PRUICSS_IRAM_PRU(PRUICSS_PRUx), 0,
    (uint32_t *) PRUFirmware, sizeof(PRUFirmware));
    DebugP_assert(status != 0);

    status = PRUICSS_resetCore(gPruIcss0Handle, PRUICSS_PRUx);
    DebugP_assert(SystemP_SUCCESS == status);

    status = PRUICSS_enableCore(gPruIcss0Handle, PRUICSS_PRUx);
    DebugP_assert(SystemP_SUCCESS == status);


    }

    1. Compile your R5F0 code.
    2. So, now R5F0 can load binaries into the PRU core for every warm reset/POR.

    Please check more details in the below example how to load PRU binaries from R5F0?

    C:\ti\mcu_plus_sdk_am64x_08_04_00_17\examples\pru_io\adc\ads85x8\am64x-evm\r5fss0-0_freertos

    Regards,

    S.Anil.