• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 30 subscribers
  • Views 1350 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.

DMA PEND behavior with AIM

Rainald Koch
Intellectual 610 points

The Reference Manual SPNU515B is not clear whether the PEND bit of a DMA channel (HW triggered by the SCI) keeps being set over a wraparound. If so, how do I probe (in the ISR for the address byte of the next telegram) whether the previous block (serial telegram) has been received completely?

Plan B is AIM = 0 and writing to HWCHENAS for each telegram (in the address-byte ISR). Question: If the previous telegram was not complete and the DMA is still pending, does the write to HWCHENAS restart the transfer (initial destination address, initial frame count)?

  • 0
    Intellectual 610 points
    Sorry, the above "over a wraparound" implies AIM = 1, which I forgot to mention.
    The uncertainty with HW requests stems from the missing information whether pending becomes active with HWCHENS or only with the first HW request.
    There is no such uncertainty with SW requests, since AIM = 1 means there is only one initial SW request, so that the pending state must continue, right?
  • 0 in reply to Rainald Koch
    TI__Guru**** 190896 points

    Hello Rainald,

      The pending bit is set when a hardware request is received independent of HWCHENS or AIM. Let's say you are using the hardware request and the AIM=1, at the end of a block transfer the PEND bit will be clear but to restart the next block the peripheral will still need to generate a hardware DMA request to the DMA module. 

      

  • 0 in reply to Charles Tsai
    Intellectual 610 points

    Thank you Charles,

    "from the first request to the last transfer of a block" is exactly the behavior I need. That time span may be exactly the same as the use of the working control packet (if "selected" means "requested": "The first time a DMA channel is selected for a transaction, the following process occurs: ...", Section 16.2.4 of the Reference Manual, Section number from SPNU515B).

    I suggest including your first sentence in Table 16-10, just before "Once set ...".

    The case AIM=1 with SW request, although mentioned in Section 16.2.8, is never used, isn't it?

  • 0 in reply to Rainald Koch
    TI__Guru**** 190896 points

    Hi Rainald,

    I could image that user uses AIM=1 with SW request to continuously read data from flash and write to CRC module for signature verification as a safety diagnostic for the memory.

  • 0 in reply to Charles Tsai
    Intellectual 610 points
    Nice point, Charles.
    So if it is true also for SW-requested DMA with AIM=1, that the time span of the pending bit being set is the same as the use of the working control packet, that shall also be mentioned in the Reference Manual (helps to comprehend the semantics of "DMA pending", which is different from "IRQ pending").

    Best regards,
    Rainald
  • 0 in reply to Rainald Koch
    TI__Guru**** 190896 points

    Hi Rainald,

      In the PEND register description in the reference manual it lists four conditions under which the PEND bit will be cleared. Three of them are related to special conditions such as parity error and bus error during transmission of the data. The normal condition to clear the PEND bit by the hardware is when either a block or a frame transfer is completed depending on the TTYPE. So when a working control packet is done with a block transfer it satisfies the condition for the PEND register to clear the corresponding bit. So to answer your question, the time span of the pending bit being set is very close to the use of the working control packet. I can't say that the time span is exactly the same because the PEND bit could be set but the corresponding channel or control packet has not really started. For example, as soon as you initiate a S/W or a  H/W request the PEND bit becomes set. However, the channel could be of lower priority compared to other pending channels. Therefore, the working control packet the newly requested channel has not been created until DMA is able to finish the higher priority channels. 

  • 0 in reply to Charles Tsai
    Intellectual 610 points

    Hi Charles,

    let me try again to find a sentence for the Reference Manual: "PEND is set when the first element transfer of a block becomes ready for arbitration."

    If this is true for both HW and SW channels, PEND won't go to zero over wraparounds (of SW channels, edited).

    regards

    Rainald

  • 0 in reply to Rainald Koch
    TI__Guru**** 190896 points

    Hi Rainald,

      I think you are looking for two answers as far as: 

     1. when is PEND set?

     2. if PEND will be cleared when the AIM=1. 

      

      For the first question, as I explained before, the moment a H/W or a S/W request is received the PEND becomes set. For H/W request the channel does NOT even need to be enabled for the PEND to set. For example, before you enable the DMA module and a peripheral request is generated, the DMA module will buffer the request and set the PEND bit. So the PEND bit is set at time 'x'. When does the transfer really start? The channel will only start after you enable the channel. If there are other channels also pending, the first element transfer of a block will not become ready for arbitration until time 'y'. So time 'x' is not equal to time 'y'. If you initiate a S/W request by writing to SWCHENAS register then the PEND will become set too. Again, this is independent of when the channel actually starts. If the DMA_EN in the GCTRL register is 0 the PEND will still set when you write to the SWCHENA register. 

     If the AIM=1 and you start the transfer by H/W request or S/W request, will the PEND remain set after one block is complete? For H/W request the PEND will be cleared after one block of transfer. The user application needs to re-trigger the transfer again so that PEND will become set again. For S/W request, I  believe the PEND will remain set after the block transfer with AIM=1 so that it will self-trigger again to repeat the same block transfer.

      

      

  • 0 in reply to Charles Tsai
    Intellectual 610 points
    So my 2nd try is also wrong. What about "PEND is set when a block of DMA transfers is requested." ?
    Unfortunately, this would only be helpful with "SW Channel Enable" renamed to "SW Channel Request" (compare "self-trigger" in your last paragraph).
    On the other hand, "re-trigger" in your last paragraph (referring to HW Channels) should read "re-enable".

    I thank you for you patience.
  • 0 in reply to Rainald Koch
    TI__Guru**** 190896 points
    Hi Rainald,
    Your understanding for "PEND is set when a block of DMA transfers is requested" is correct. I agree the SW Channel Enable can be interchanged in meaning as SW Channel Request.
  • 0 in reply to Charles Tsai
    Intellectual 610 points

    > The pending bit is set when a hardware request is received independent of HWCHENS or AIM. (your first answer to this thread)

    This is also independent of TTYPE, isn't it? So PEND gets active IFTCOUNT times if TTYPE = 0.

    I erred in "exactly the behavior I need". I think I should test for CFTCOUNT>0 instead of PEND == 1. I am going to open a new thread for what to do if CFTCOUT > 0.