• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 99 subscribers
  • Views 679 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.

Question about PCIe in C6678

ZAKARIA BOURZOUK
Intellectual 560 points

Hi,

I work on the communication between two DSPs ( EP and RC ). I have two questions and I would like to have their answer :

Question 1 : When I debug my programs for the first time, the memory write transaction for example is done with success. Now , when I re debug for a second time the program, the transfer does not pass !!

I must  turn OFF the two target ( EP and RC ), and again turn ON , after  that , the transfer pass successful.

I think the PCIe module trun OFF automatically when i debug the program for a second time !! it's  true? 

Question 2 :  my second question is about the MSI :

Suppose in our test, the EP sends an interrupt to the RC.

So the EP can know that the interruption has not been received in the RC side ?

can you give me an explanation of this questions please ?!

thank you,

Sincerely,

Zakaria.

  • 0
    TI__Mastermind 28085 points
    Hi,

    Ans1: Some of the C66x CorePacs do not wake up on RESET reset when the device is connected via CCS. When the device is connected via CCS the device stays in the emulation debug state. If the RESET reset is applied while the device is in the emulation debug state it causes some of the C66x CorePacs to go into an unknown state and they don’t start execution.

    Resets using POR and RESETFULL does not exhibit this behavior. This does not affect the normal usage of the device when CCS/emulator is not connected to the device since the device is not in emulation debug state when reset is applied using RESET pin. This behavior can only happen in the lab environment where CCS/emulator is connected to the device. For more information refer "Usage Note 22 Core Wake Up on RESET Usage Note" on C6678 Silicon Errata document(SPRZ334G).

    Ans2: The memory write transactions to generate MSI interrupts in RC are actually targeted at MSI_IRQ register. The MSI interrupt is generated as a result of the one of 32 events that is triggered by a write of MSI vector value to MSI_IRQ register in RC. Before the end point devices can issue MSI interrupts, the MSI address and data registers must be configured by system software to make sure the MSI_IRQ registers could be accessed correctly with proper MSI vector value.

    If there is no system software supported, the user application needs to make sure EP could issue memory write transaction to MSI_IRQ register in RC with proper MSI vector value to generate MSI interrupt in RC. For more details about how MSI interrupts are expected to behave, please see the PCIe standard specifications.

    Thanks,
  • 0 in reply to Ganapathi Dhandapani95
    Intellectual 560 points
    Hi,

    thank you for your quick response.

    On the second question, how can the EP know that the interruption he sent to RC was received ?

    thank you,

    Sincerely,

    Zakaria.
  • 0 in reply to ZAKARIA BOURZOUK
    TI__Mastermind 28085 points
    Take a look at below MSI interrupt related threads:
    e2e.ti.com/.../801037
    e2e.ti.com/.../709929

    Thanks,
  • 0 in reply to Ganapathi Dhandapani95
    Intellectual 560 points
    Hi,
    thanks Mr.Ganapathi for your answer.

    I have an other question about MSI latency , So i have two scénario :

    The first is: one EP send 1000 MSI_0 ( vector 0 ) to the RC

    ------------------------EP-------------------------------------------
    ----for (j = 0; j < 1000; j++) { -----
    ---- -----
    ---- *((volatile UINT32 *) 0x60000054) = 0x0; -----
    ---- cycleDelay(5500); -----
    ---- } -----
    ----------------------------------------------------------------------

    The second test is: two EPs send 1000 MSI_0 ( vector 0 , 8 , 16 , 24) to the RC

    ------------------------EP1-----------------------------------------
    ----for (j = 0; j < 1000; j++) { -----
    ---- -----
    ---- *((volatile UINT32 *) 0x60000054) = 0x0; -----
    ---- cycleDelay(6100); -----
    ----*((volatile UINT32 *) 0x60000054) = 0x8; -----
    ---- cycleDelay(6100); -----
    ---- } -----
    ----------------------------------------------------------------------
    ------------------------EP2-----------------------------------------
    ----for (j = 0; j < 1000; j++) { -----
    ---- -----
    ---- *((volatile UINT32 *) 0x60000054) = 0x16; -----
    ---- cycleDelay(6100); -----
    ----*((volatile UINT32 *) 0x60000054) = 0x24; -----
    ---- cycleDelay(6100); -----
    ---- } -----
    ----------------------------------------------------------------------

    N.B.: the CycleDelay(5500) introduce 5500 cycle so that the RC can receive all interrupt ( 1000 interrupt )
    N.B.: the CycleDelay(6100) introduce 6100 cycle so that the RC can receive all interrupt ( 4000 interrupt )

    So my question is , why in the first scenario we work with cycleDelay(5500) and in the second test the argument of cycleDelay take (6100) ????
    can you give me an explanation of this problem please ?!

    thank you,

    Sincerely,

    Zakaria.
  • 0 in reply to ZAKARIA BOURZOUK
    TI__Mastermind 28085 points
    Hi,

    For my understanding, single EP send 1000 MSI_0 ( vector 0 ) to the RC takes 5500 cycle delay and two EP send 1000 MSI_0 ( vector 0 ) to the RC takes 6100 cycle delay. Is it correct?

    The RC device can perform a memory write into the MSI_IRQ register over the PCIe link to generate one of 32 EP interrupts. Note that the PCIESS will follow PCIe MSI rules and will not necessarily accumulate multiple writes to the same MSI vector. Only one of such writes is guaranteed to be processed and subsequent writes on the same vector arriving before the interrupt status is cleared may be lost.

    Thanks,
  • 0 in reply to Ganapathi Dhandapani95
    Intellectual 560 points
    Hi,

    No Mr. Ganapathi , the 5500 and 6100 cyles are the minimum time to send successive interruption for each case.

    for example, in singel EP , we must wait 5500 cycle to send the second interrupt , also , in two EP case , we must wait 6100 cycles to send the second interrupt for each EP.

    I think the 5500 cycles become 6100 in two EP cases , because we write the data in the same address 0x60000054 , is it logic ?


    thank you,

    Sincerely,

    Zakaria.
  • 0 in reply to ZAKARIA BOURZOUK
    TI__Mastermind 28085 points
    In two EP case, RC takes more cycle for respond both EPs MSI interrupts. The PCIESS will follow PCIe MSI rules and will not necessarily accumulate multiple writes to the same MSI vector.
  • 0 in reply to Ganapathi Dhandapani95
    Intellectual 560 points
    okay, thank you Mr. Ganapathi
  • 0
    Guru 13202 points

    As to your second question, there is no native mechanism, which would let EP know about interrupt processing state. MSI is almost identical to memory write transaction, which is "send and forget". Unless you employ some ACK logic, there is no way to know the interrupt was serviced.

    Perhaps your question was a matter of understanding. If you got a real situation about that, do you mind to share more details, so we could suggest reasonable solution.

  • 0 in reply to Victor Kazmirenko
    Intellectual 560 points
    thank you , the truth is that I am not a real scenario , I just wanted to get an idea.

    I understood what you said, thank you again.

    thank you,

    Sincerely,

    Zakaria.