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.

Why are is the DMA one-shot mode and high-priority mode incompatible on the TMS320F2837xD?

Other Parts Discussed in Thread: TMS320F28062, TMS320F28335, TMS320F28377D

The TMS320F2837xD Technical Manual Revision E has updates to the DMA section 4:

Section 4.5.2 Channel 1 High Priory Mode now contains the note:

NOTE: High-priority mode and one shot mode may not be used at the same time.

Section 4.6 Address Pointer and Transfer Control also has a similar note added for One Shot Mode.

- Why have these notes been added?

- What happens when High-priority mode and one shot mode are both used at the same time?

- Do other members of the C2000 also have a similar issue? (There are no similar notes for the TMS320F2833x or TMS320F2806x.)

- Why is this issue not included in the Silicon Errata for the TMS320F2837xD?

Application Information

We use both high-priority mode and one-shot mode in our firmware for the TMS320F28377D. This has been operational for >12 months and we have not noticed any problems associated with the DMA. Similar code has been operating on the TMS320F28335 and TMS320F28062 for years without incident.

 In our application we use software initiated DMA transfers of relatively large blocks and hardware initiated transfers of smaller blocks. Software initiated DMA transfers and some hardware initiated transfers have a single trigger for each transfer. To share DMA bandwidth we prefer to use one-shot mode with a small burst-size. Then transfers can occur concurrently for several DMA channels (each burst by burst). Figure 4.7 certainly implies that this is possible. (The yes branch from ONE-SHOT == 1? is labelled as a point where state machine branches to next channel are possible.) The hardware initiated DMA with the lowest latency requirement is set for CH1 and the high-priority mode is enabled. The scheme would probably work OK without the high-priority mode enabled, but the timing analysis would be more difficult. We will only disable the high-priority mode if absolutely necessary.

  • Simon,

    I will talk to our design team and get back to you.

  • Simon,

    Here's what happens on channel 1 when high-priority and one-shot mode are enabled at the same time:

    First trigger: One burst from the first transfer is copied.
    Second trigger: All remaining bursts from the first transfer are copied plus one burst from the second transfer.
    Third trigger: All remaining bursts from the second transfer are copied plus one burst from the third transfer.
    Fourth trigger: All remaining bursts from the third transfer are copied plus one burst from the fourth transfer.
    etc.

    I'm still looking into the documentation history. I was on vacation for Thanksgiving week (Nov 23 - Nov 27).

  • Adam,

    Thank you for detailed explanation of the problem on the affected DMA channel. I would like to know more about the scope of the problem - which channels can be affected?

    Case 1: High priority mode enabled. Channel 1 configured for one-shot mode. I assume that Channel 1 is affected as you described.

    Case 2: High priority mode enabled. Channel 1 not configured for one-shot mode. (Setup for 1 burst per trigger on hardware trigger.) Channel 2 is configured for one-shot mode. (Setup for software trigger to transfer a large block in several bursts.) Expected operation: Channel 2 transfers the whole block on receipt of a software trigger. If a Channel 1 trigger occurs, the Channel 2 transfer will suspend at the end of the current word, the Channel 1 burst transfer will happen, then the Channel 2 block transfer will complete. Does case 2 happen as expected, or is Channel 1 or Channel 2 affected by the problem?

    Our application setup is like Case 2.

    Thanks for your continuing help.

    Simon

  • Simon,

    Case 2 should work. I'm double-checking with our design team to confirm.
  • Simon,

    I have confirmed that using other channels in one-shot mode while channel 1 is in high-priority mode will work correctly.

    Also, if both one-shot mode and high-priority mode are enabled on channel 1, the other channels will work correctly. Only channel 1 shows the erroneous behavior.

    I will work on updating the documentation for our older devices. We're going to release erratas for this issue just to make sure nobody misses it.

  • Adam,

    Many thanks to you and the design team for the complete explanation of this issue.

    I am relieved to know that this does not affect channels configured for one-shot mode, other than channel 1.

    I suggest a minor update in the next revision of the documentation, to the effect that one-shot mode should not be used on channel 1 if high priority mode is enabled.

    Thanks for your help.

    Simon