How do I GUARANTEE input termination of DMA using TRQ input?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Hi,

I'm doing some advanced DMA operations.  One of the advance techniques needs the TRQ input to the DMA component.

I'm having difficulty GUARANTEEing that the rising edge of the TRQ terminates the current DMA operation.

As an example of the issue, I've modified the program used in the Cypress-supplied App note "001-84810_AN84810_-_PSoC_3_and_PSoC_5LP_Advanced_DMA_Topics".

It replaces the ADC with a WaveDAC8 generating a sine wave and is clocked by an external clock of 100KHz.  The DMA moves the wave data in the WaveDAC8 to the VDAC8 data register.   This regenerates the sinewave to the pin assigned to the output of the VDAC8.

When you press on the switch (P2.2) on the CY8CKIT-059, the rising edge usually is ignored.  after usually many presses, the TRQ is respected and the indefinite DMA transfer is terminated.

I suspect I either didn't set up the SW configuration correctly or the HW state logic is not correct (or both).

I would appreciate understanding what I am missing.

 

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

To all,

I would like to thank everyone for their input.

I'm still in pursuit of a definitive answer as to how to use the TRQ input properly.

Here are my findings to date:

Most of the Cypress documentation regarding the TRQ input and how to use it can be found in the DMA component datasheet and two AppNotes.

  • "001-52705_AN52705_PSoC_3_and_PSoC_5LP_Getting_Started_with_DMA.pdf"
  • “001-84810_AN84810_-_PSoC_3_and_PSoC_5LP_Advanced_DMA_Topics.pdf”

Info about TRQ is a bit ambiguous.  The only detail listed is:

Hardware Termination (trq): When this option is set to true, another input terminal (trq) is displayed in the component. If TD termination is enabled, a rising edge on this terminal stops an ongoing DMA transaction. Note that trq terminates a TD chain only if there is an ongoing DMA burst transaction. Refer to the component datasheet for more details.

Cypress provided some level of DMA phase timing diagrams as shown below for an Inter-Spoke transfer.  No detail is provided as to where in this timing is the TRQ signal validated.  I have requested a version of this diagram indicating the TRQ validation window.

Len_CONSULTRON_0-1624887719709.png

Observations

With my experiments, my conclusion at this time is that the TRQ generally works if the DMA burst is a multi-byte per burst transfer.  For example, if you are transferring 100 bytes with one burst, the TRQ signal DURING the active transfer will terminate the TD's transfer.  (The timing of the termination within the transfer is still in question.)  

On the other hand in a single-data burst transfer, TRQ is almost entirely ignored.  This is because the timing of the rising edge of the TRQ is critical.  The project I provided with the first post of this thread is a single-byte per burst with an infinite looping TD.  Each request is based on the sampling clock of the 100KHz.  I have not found a reliable means of terminating the TD with the switch input.  Occasionally the timing of the Switch input meets the tight timing requirements.

The issue that is if the TRQ signal is active when the DMA is NOT active, it is ignored.  Additionally, if the TRQ is active when the next DMA burst is requested, the TRQ signal is ignored.   The TRQ rising edge apparently must be detected at sometime during the DMA transfer phase.

Alternate Solution

I have created a TRQ-equivalent functionality using a technique I call "DRQ-gating".  Since each single-byte burst is requested individually, I have created logic to enable/disable the DRQ signal to pause (halt) or stop (terminate) the DMA transfer.  The project is attached on this post.

I am working with someone from Infineon to get a more definitive answer about the proper use of TRQ to share with this forum.

UPDATE:  Oops forgot the DRQ-gating project upload.  It's now attached.

 

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

9 Replies
odissey1
Level 9
Level 9
First comment on KBA 1000 replies posted 750 replies posted

Len, 

Can you try to sync trq from button with WaveDac8 clock? I believe that for trq to work, it should come together with drq (which makes it quite useless)

 

0 Likes
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

/odissey1,

I placed a sync component between the switch input and the TRQ signal with the WaveDAC8 clock as the clocking source.  No improvement.

Thanks for the suggestion.  I've got a ticket in with Infineon.  Hopefully we'll come up with an answer being closer to the source.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
EvPa_264126
Level 7
Level 7
500 replies posted 250 replies posted 100 likes received

It seems that the TRQ signal should appear only at the moment of the active phase of the transaction.
There were several topics about this. Here is one of them:
PSoC5LP : The trq terminal of DMA componet  

0 Likes

Evigeny,

Your trq project does work with TRQ terminating the DMA with a DMA_REQUEST_PER_BURST = 0 as you indicated.  However my project is trying to control the rate of the update of the VDAC8 by sending the external clock to the DRQ for each 1 byte of DMA transfer.  This requires  DMA_REQUEST_PER_BURST = 1.  In this case, it appears I can't practically synchronize the rising edge of TRQ to the active transfer.

In my case, the single byte burst and each byte must be requested separately there is no HW feedback signal to indicate WHEN the DMA transfer is occurring.  Normally it will occur within one or two BUSCLK cycles from the DRQ active signal.   However due to potential DMA priority disputes, it might be delayed further.

If Cypress had incorporated a DMA_CHANNEL_BUSY HW signal into their design, we could have used it to synchronize the TRQ.

Another solution may have been that the TRQ signal is tested for active just before DMA transferring the data.  That way the TRQ can be held active for as longer as needed for single-data per burst transfers triggered by DRQ.

I have another TRQ-related project I haven't posted up that I want to work with Infineon to understand what is going on.

In this project, I'm transferring up to 4095 bytes in one burst.   In this way it is nearly identical to your trq project.  However, I have a HW signal that causes TRQ to go active on specific criteria.  When it does, you can see that the transfer is halted for a few 6 additional BUS_CLK cycles then it continues for 10 additional byte transfers before terminating early(-ish).   I was expecting the DMA termination to occur once TRQ was sensed.  It transferred 10 additional bytes to the destination before it terminate.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
lock attach
Attachments are accessible only for community members.
EvPa_264126
Level 7
Level 7
500 replies posted 250 replies posted 100 likes received

If there is only one TD in the chain, then trq can only interrupt it and start again.
In your example, this can be implemented artificially by increasing the transaction time using transferCount.
It doesn't do anything, I'm just trying to figure out how it works.

 

0 Likes

EvPa,

Thank you for your attempt to get TRQ to work.

I've tried your code.  I could not get your same results of Pin_d_done to indicate the termination of the DMA channel.

I've also modified your project to include the 'synchro' DFF with and 'enable' input that only enables it with the switch active low to allow the TRQ clock to go through to the next DFF.

Still no TRQ action.

In a later post, I will provide a more detailed post with a project that substitutes the TRQ signal with a 'gated' DRQ input.  It works well and is much closer to my design intent.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
lock attach
Attachments are accessible only for community members.
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

To all,

I would like to thank everyone for their input.

I'm still in pursuit of a definitive answer as to how to use the TRQ input properly.

Here are my findings to date:

Most of the Cypress documentation regarding the TRQ input and how to use it can be found in the DMA component datasheet and two AppNotes.

  • "001-52705_AN52705_PSoC_3_and_PSoC_5LP_Getting_Started_with_DMA.pdf"
  • “001-84810_AN84810_-_PSoC_3_and_PSoC_5LP_Advanced_DMA_Topics.pdf”

Info about TRQ is a bit ambiguous.  The only detail listed is:

Hardware Termination (trq): When this option is set to true, another input terminal (trq) is displayed in the component. If TD termination is enabled, a rising edge on this terminal stops an ongoing DMA transaction. Note that trq terminates a TD chain only if there is an ongoing DMA burst transaction. Refer to the component datasheet for more details.

Cypress provided some level of DMA phase timing diagrams as shown below for an Inter-Spoke transfer.  No detail is provided as to where in this timing is the TRQ signal validated.  I have requested a version of this diagram indicating the TRQ validation window.

Len_CONSULTRON_0-1624887719709.png

Observations

With my experiments, my conclusion at this time is that the TRQ generally works if the DMA burst is a multi-byte per burst transfer.  For example, if you are transferring 100 bytes with one burst, the TRQ signal DURING the active transfer will terminate the TD's transfer.  (The timing of the termination within the transfer is still in question.)  

On the other hand in a single-data burst transfer, TRQ is almost entirely ignored.  This is because the timing of the rising edge of the TRQ is critical.  The project I provided with the first post of this thread is a single-byte per burst with an infinite looping TD.  Each request is based on the sampling clock of the 100KHz.  I have not found a reliable means of terminating the TD with the switch input.  Occasionally the timing of the Switch input meets the tight timing requirements.

The issue that is if the TRQ signal is active when the DMA is NOT active, it is ignored.  Additionally, if the TRQ is active when the next DMA burst is requested, the TRQ signal is ignored.   The TRQ rising edge apparently must be detected at sometime during the DMA transfer phase.

Alternate Solution

I have created a TRQ-equivalent functionality using a technique I call "DRQ-gating".  Since each single-byte burst is requested individually, I have created logic to enable/disable the DRQ signal to pause (halt) or stop (terminate) the DMA transfer.  The project is attached on this post.

I am working with someone from Infineon to get a more definitive answer about the proper use of TRQ to share with this forum.

UPDATE:  Oops forgot the DRQ-gating project upload.  It's now attached.

 

Len
"Engineering is an Art. The Art of Compromise."

Hello Len, 

I think you forgot to upload the version where u used "DRQ-gating".

I am facing the same problem as u do, with the trq signal.

Any word from Infineon un the updated timing diagram with the trq?

Thank you!

0 Likes

Mihai,

Thanks for noticing I'm missing the DRQ-gating project.  It is now posted in the solution as it was suppose to be.

No.  I haven't heard from Infineon yet about it.

Len
"Engineering is an Art. The Art of Compromise."