• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 103 subscribers
  • Views 392 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.

AM5726:SPI Assert to CallBack Timing

Hidekazu
Intellectual 880 points
Other Parts Discussed in Thread: ADS131A02

Hi,Expert

We are currently using SPI2 to get AD data from TI's ADS131A02 ADC.

As a product specification, the AD data is imported in 8 usec cycles.
In order to run in 8usec cycles, AD data needs to be captured at about 5usec. In reality, however,
it takes more than 20 usec for each acquisition.
However, in reality, it takes more than 20usec for each acquisition.

The test summary and waveform data are as follows.

Questions:

(1) It takes 1.4us from DRDY assertion to DRDY callback.
　  I don't understand why it takes 1.4us for a simple GPIO interrupt.
    Is this 1.4us a reasonable amount of time?
    If it is, where does it take that long? (BIOS or peripherals?)

(2) DRDY's Callback sends a request to the task, and then calls the driver's SPI_transfer().
　  It takes 2.4us from Callback to SPI_transfer(). The time from Callback to SPI_transfer() after dispatch is 2.4us.
    This is almost the time for dispatching.
    Is this time correct?

(3) Assuming that (2) is a reasonable time,
    I want to call SPI_transfer() directly from DRDY's Callback, but I cannot call SPI_transfer() directly from HWI
    because I am waiting for semaphore in SPI_transfer().
    Is there any way to call it directly?

Best Regards,
Hidekazu

  • 0
    Intellectual 880 points

    Hi,Expert

    When the customer investigated the cause of the delay,
    It turns out that access to peripheral registers is very slow.

    In the case of memory access, the cache may be effective, and one access will be completed in 3 to 4 cycles.
    On the other hand, in the case of peripheral register access, it takes about 180 cycles for one access.
    Therefore, you only need to access the register several times to usec.

    I'm very sorry, but I'm urgently confirming this matter alone.
    Could you please?
    If you do not solve this problem, you will not be able to move forward, so you are in great trouble.
    If you have a setting that makes peripherals faster, could you please tell me how to solve it? ..


    Best Regards,
    Hidekazu

  • 0 in reply to Hidekazu
    TI__Prodigy 605 points

    Hi Team,

    This question was asked 11 days ago. Would you give them the feedback?

    Best regards,

    Yuta Ishii

  • 0
    Intellectual 880 points

    Hi,Expert

    I am having a very hard time finding a solution to this problem.
    Could you please comment just on the research points and reference information?

    Best Regards,
    Hidekazu

  • 0
    TI__Guru**** 477995 points

    Hi Hidekazu,

    Please find answers to your questions below.

    Hidekazu said:

    (1) It takes 1.4us from DRDY assertion to DRDY callback.
    　  I don't understand why it takes 1.4us for a simple GPIO interrupt.
        Is this 1.4us a reasonable amount of time?
        If it is, where does it take that long? (BIOS or peripherals?)

    It can potentially take so much. BIOS typically implements master callback/ISR and then calls appropriate ISR of the interrupt. Also one question, anything else running in the system? Because if some ISR is active, then this ISR can get delayed. 

    Hidekazu said:
    (2) DRDY's Callback sends a request to the task, and then calls the driver's SPI_transfer().
    　  It takes 2.4us from Callback to SPI_transfer(). The time from Callback to SPI_transfer() after dispatch is 2.4us.
        This is almost the time for dispatching.
        Is this time correct?

    Again this depends on the other things/tasks/ISR/SWI running in the system. If there is a higher priority task waiting, then it will server higher priority task first..

    Hidekazu said:
    (3) Assuming that (2) is a reasonable time,
        I want to call SPI_transfer() directly from DRDY's Callback, but I cannot call SPI_transfer() directly from HWI
        because I am waiting for semaphore in SPI_transfer().
        Is there any way to call it directly?

    Where do you wait for semaphore? in the driver? If there is a semaphore wait in the driver in SPI_transfer API, then we cannot call it from callback. 

    One question, in this time critical transfer, isn't it possible to use DMA mode, instead of CPU mode? If you have data ready to be transferred, you could transfer them using DMA..

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 880 points

    Hi,Brijesh

    Thank you for reply.

    As I have commented in this thread, it turns out that the problem is not dependent on the software structure,
    but on the time required for peripheral register access, and we are being asked to find a solution.

    When the customer investigated the cause of the delay,
    It turns out that access to peripheral registers is very slow.

    In the case of memory access, the cache may be effective, and one access will be completed in 3 to 4 cycles.
    On the other hand, in the case of peripheral register access, it takes about 180 cycles for one access.
    Therefore, you only need to access the register several times to usec.
    (We are running the system in DMA mode.)

    I'm very sorry, but I'm urgently confirming this matter alone.
    Could you please?
    If you do not solve this problem, you will not be able to move forward, so you are in great trouble.
    If you have a setting that makes peripherals faster, could you please tell me how to solve it? .

    Best Regards,
    Hidekazu

  • 0 in reply to Hidekazu
    TI__Guru**** 477995 points

    Hi Hidekazy,

    From which core are you trying to access the SPI register? Also 180 cycle for which operation, read or write or read-modify-write? Also 180 cycle of which clock? 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 880 points

    Hi,Brijesh

    The measurement conditions are as follows.

    The access is from MPU0.
    The operation is a write operation.
    The cycle is MPU0.

    Best Regards,
    Hidekazu

  • 0 in reply to Hidekazu
    TI__Guru**** 477995 points

    Hi Hidekazu,

    I think MPU is running at 1GHz, so does it mean it takes 180 cycles of 1GHz to write to SPI register? 

    One more question, if you are already using DMA, where does the CPU overhead come? This is because there is no CPU intervention between each transfer..

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Intellectual 880 points

    Hi,Brijesh

    The customer was able to read the data at the desired cycle by remaking the driver with the following design specifications.

     1.No access to the peripherals as much as possible.
     2.Use a lot of DMA.

    Best Regards,
    Hidekazu