• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 1094 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.

[C6655] The assert timing of uPP WAIT pin (Receive mode case)

Naoki Kawada
Guru 19890 points


Hi,

I'm just reading uPP user's guide.
I could not understand the assert timing of uPP WAIT pin.

Let me assume that uPP has been configured as receive mode. After configuring built-in DMA via UPID0/UPID1/UPID2 registers (order free to invoke DMA ?), DMA would get started to work. An actual transfer would start by clocking from uPP host. After a transfer has been completed for the dedicated window, an interrupt can happen if UPIES.EOWI=1. The ISR will configure DMA for the next window....The system is working like this.

In this use case, when WAIT pin gets asserted ? I'm wondering if 
- It would be during initial uPP setup.
- It would be the time between "the timing of a (previous) DMA completion" and "the timing for next DMA configuration in ISR".

Is my understanding correct ?

Best Regards,
Kawada

  • 0
    TI__Mastermind 20790 points

    Kawada,

    WAIT Signal:
    It is driven by receiver. Asserts to request a pause in the current transfer. An I/O channel configured in receive mode immediately asserts its WAIT signal.
    Please go through the section "2.5.5 WAIT Signal" in the Keystone UPP User Guide(spruhg9).
    The below wiki will be useful for UPP,
    http://processors.wiki.ti.com/index.php/Introduction_to_uPP

  • 0 in reply to Pubesh
    Guru 19890 points
    Hi Pubesh,

    Thanks for your answer. Actually, I had confirmed the descriptions you suggested. I'm asking because I didn't understand what can make uPP busy (what can make wait pin active). I guessed that wait pin could be active at the race conditions of DMA setup, which I mentioned in the previous post. Another thought was full state of internal FIFO. What do you think of this ?

    I'm afraid I ask you so much, but please let me confirm one more thing.
    In receive mode, DMA can read data from internal FIFO (512 bytes total), but its size per transaction could be restricted to 64 bytes because the internal FIFO is being divided into eight 64byte blocks. This is described in UG:
    - 2.4.1 DMA Programming Concepts
    - 2.11 Transmit and Receive FIFOs
    Now let's assume the the window size is 32 bytes (just a extreme example). In this case, a block in FIFO are not fullfilled. So I'm wondering if DMA would wait for another incoming 32 bytes data and then start to work... If my understanding is correct, this means uPP host has to take care about the transfer size. Also, if something noise could be existing on the active edge of uPP clock, uPP might be able to latch incoming data doubly. This is possible scenario to have size inconsistency in FIFO.
    If we had such inconsistency in FIFO, how could we detect/reset this condition ?

    Best Regards,
    kawada
  • 0 in reply to Naoki Kawada
    TI__Mastermind 20790 points
    Kawada,
    I have requested the team about your query, reponse will be delayed due to holidays/vacation. Thanks for your patience.
  • 0 in reply to Pubesh
    TI__Guru* 84865 points
    Kawada-san
    You might a few additional posts on uPP in OMAPL1x forums useful to understand the WAIT behavior and functionality

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/65198

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/216417

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/83542

    Regards
    Mukul
  • 0 in reply to Mukul Bhatnagar
    Guru 19890 points
    Hi Mukul,

    Thanks for your information. The post you suggested says, uPP (Rx) does not assert WAIT pin during normal operation.
    I'm wondering if this is really correct. Let's assume uPP (Rx) has not completed to setup DMA. And at this point, the data is incoming. In this case, data can be lost if WAIT pin was not asserted.

    And the posts does not answer to my questions about the inconsistency in FIFO.
    Do you have any answers for that ?

    Best Regards,
    Kawada
  • 0 in reply to Naoki Kawada
    TI__Guru* 84865 points

    Hi Kawada-san

    I guessed that wait pin could be active at the race conditions of DMA setup, which I mentioned in the previous post. Another thought was full state of internal FIFO. What do you think of this ?


    I have confirmed from design that the WAIT signal only asserts on emulation halts and clkstop ( on chip power sleep controller gating of uPP module clocks etc). It does not get asserted on state on internal FIFO / data availability etc. 

  • 0 in reply to Mukul Bhatnagar
    Guru 19890 points

    Hello Mukul,

    Thank you very much for the clarification. Okay. In order to get correct data from uPP Tx side, I understand that it is better to configure uPP Rx DMA before starting uPP Tx Transfer (because a WAIT PIN does not get asserted during the time which Rx DMA is not configured).

    Best Regards,
    Kawada