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.

TMS320C5517: Urgent/Confirm the timing/condition to happen the INTRTX.

Guru 24520 points
Part Number: TMS320C5517

Hi TI Experts,

Please let me confirm the following question.
  Note: This question is related to the following E2E post.
   

[Question.1]

Would you please teach me the timing or condition to happen the interrupt of INTRTX?
I think that this will happen when device complete transmitting the FIFO data to Host.

[Question.2]
If my understanding is correct, what do you think the cause to happen the INTRX(EP1TX) interrupt twice within very short duration(40us) even though the data did not complete transmitting when the CPU clock was 200MHz?

At this time, the CPU over-write the data on FIFO even though the data did not complete transmitting. If you need more data to resolve this issue, please let me know. They have used the following environments.

Board: Custom board
CAF version: v02.00.02.04
CSL version: v3.07.00

[Question.3]
Could you please reproduce this issue by modifying the CAF in order to run the C5517EVM on your side?

We must answer this question by next Tuesday in Japan time. So, please help us.
Best regards.
Kaka

  • We're looking into this. Feedback will be posted here.

    Best Regards,
    Yordan
  • Hi Yordan,

    Please provide your answers as they are prepared.

    Best regards.
    Kaka
  • Hi Yordan,

    Do you have any updates?
    We need to answer this question today. Please help us.

    Best regards.
    Kaka
  • Hi Kaka-san,

    Q1

    The register INTRTX got set when the corresponding  EP (0-4) TX FIFO is emptied by the USB core (copied from the FIFO to the internal buffer in the USB core), not necessary the host have received it. Then, the INTMASKEDR1 will be set accordingly which will cause the USB interrupt. Once the USB ISR processes it, INTMASKEDR1 will be cleared by write the same value to INTCLRR1 (usbRegisters->INTCLRR1 = pContext->dwIntSourceL). In order to clear the  INTRTX, the EP TX FIFO needs to be filled by CPU.

    Q2

    There two possibilities here:

    1. The SOF interrupt comes before the TX interrupt, because in ISO mode the USB host sends the IN token at the SOF, it takes some time for the TX interrupt to come in (C5517 receives IN token, USB core copies the TX data from TX FIFO to the internal buffer, sends the TX interrupt). If the SOF got processed before the TX comes in, then you will get two interrupt per ms.

    2. The RX interrupt may play a role here, if the playback path is used. The RX interrupt may come in different time as the TX interrupt. If they are not processed in the same USB ISR access, then you will get two interrupt per ms.

    Q3

    We are in the process to make our USB audio example work on C5517 EVM at 200Mhz. We will let you know the result soon. As the reference point, all our USB examples in the CSL (USB CDC, HID, MSC and endpoints) have been tested on C5517 EVM at 200Mhz and they are all running properly.

    Best regards,

    Ming

  • Hi Ming,

    Thank you for your comments. I will check your comments, and if I get more questions, please let me confirm them.
    By the way, would you please provide answer for following question within few hour?

    TI have verificated C5517 operation on USB core behavior in all operation frequency range up to 200MHz. So, may I answer to my customer that TI guarantees to work the USB function on TMS320C5517 with 200 MHz CPU clock?

    Best regards.
    Kaka
  • Hi Ming,

    We could get this answer from your tema. By the way, we got a question from my customer.
    According to your comments, the INTRTX interrupt will be set when the USB core copy the FIFO data to internal buffer. Would you please teach me how customer decide the correct timing to write the FIFO before copying the data by USB core?
    I think that there is a potential to overwrite the FIFO data before sending the data to USB host if they used the INTRTX interrupt as writing timing.
    Actually, when used the INTRTX interrupt as writing timing, it seems that the USB core copying the data before sending the data to USB when the CPU run at 200MHz if used the CAF.

    Best regards.
    Kaka

  • Hi Kaka-san,

    What I meant is that the INTRTX interrupt will be generated when the USB core (the Mentor core) copies the data from TX FIFO to its internal buffer (inside the Mentor core. it is a different area than the FIFO memory. The Mentor core will then copy the data from its internal buffer to the USB host). The TX FIFO will be free after that, therefore the potential overwrite will not happen no matter how fast the CPU runs.

    The correct timing is CPU needs to fill the TX FIFO whenever the INTRTX occurs (means the TX FIFO is empty and ready to accept new data).

    Here is the event sequence for USB TX transaction:

    1. The TX FIFO is filled with data to be transferred.

    2. The SOF interrupt received by USB device (one per ms in full speed mode).

    3. The SOF interrupt is serviced by CPU (while the IN token is coming at the same time)

    4. After receiving the IN token, the USB core copies the data from TX FIFO to its internal buffer.

    5. INTRTX is triggered, because the TX FIFO is empty.

    6. The data is transferred from USB core internal buffer to USB host (while the INTRTX is being serviced by CPU at the same time)

    7. repeat 1-6. 

    Ming

  • Hi Ming,
    Please let me confirm about your comments about INTRTX event.

    1. CPU Write the data to TX FIFO on C55x device.
    2. Set the TXPKTRDY
    3. Copy the TX FIFO data to buffer on USB core (Mentor Core)
    4. Happen the INTRTX interrupt.
    5. CPU can be write the new data on TX FIFO.
    It means that Mentor core will not copy the data until free the internal buffer. This is why the overwrite will not happen in any CPU clock.
    Is my understanding correct?

    Best regards.
    Kaka
  • Hi Ming,

    My customer said that this problem is caused by CSL v3.07.00 bug.
    If possible, please check it of USB driver whether there is any problem.

    Best regards.
    Kaka
  • Hi Kaka-san,

    Your understanding is correct.

    Ming

  • Hi Kaka-san,

    We do not aware of any outstanding issues with the USB driver in CSL rev 3.7.0. If your customer found anything please let us know the details. We will address it as soon as possible.

    Best regards,

    Ming
  • Hi Kaka-san,

    Please explain in details about the USB driver issue caused by the CSL 3.7.0 bug.

    Ming

  • Hi Kaka-san,

    Please explain in details about the bug in CSL 3.7.0 which cause the USB driver issue.

    Ming
  • Kaka-san
    I would also recommend that we converge on using a single E2E thread and close the other ones, as all of them are related and we should just use one of them.
    Please pick the thread that is most relevant and we will close the others on the same topic
  • Hi Mukul.

    I got it. I close this thread.

    Best regards.
    Kaka