PSoC™ 5, 3 & 1 Forum Discussions

How to prevent unwanted DMA transactions after enabling a DMA channel with queued transaction requests.

Summary:
If a disabled DMA channel receives a request to perform a transfer, the request will be queued up similar to a pending interrupt.  When the channel is enabled, the pending transfer request will be executed, resulting in a transaction that may not be desired.

The workaround is to queue up a “terminate channel” request.  This request takes precedence over the transfer request.  As soon as the channel is enabled, the terminate request is executed instead of the transfer request.  This clears the pending transfer requests and disables the channel.  The channel must be re-enabled afterward to function as intended.

Details:
This problem was discovered when an ADC End Of Conversion (EOC) was connected to the DMA ReQuest (DRQ) terminal of a DMA channel.  The DMA channel was only really needed during a brief high speed sampling window.  The ADC would be used normally other times, with software requesting a start of conversion and the "conversion done" bit being polled by the CPU to determine when the conversion was complete.

It was observed that when the ADC was disabled and the DMA channel was turned on (enabled), a sample would mysteriously appear in RAM.  This was occurring even though it was guaranteed that the EOC signal was not asserted when the channel was enabled.

It was determined that when the ADC was used normally, the EOC was asserting the DRQ of the disabled DMA channel. This request was remembered by the DMA channel, even though the DMA channel was disabled.  When the channel was enabled, this "remembered" DRQ was being executed immediately, resulting in an unexpected DMA transfer.

The fix is to assert a CPU request to terminate the chain before enabling the channel.  By doing this, both requests (the transfer request and the terminate request) will be queued up in the DMA channel, waiting for the channel to be enabled.  When the channel is enabled, the terminate request will take precedence over the transfer request and the DMA channel will terminate immediately, erasing the pending transfer request.  The channel needs to be re-enabled after being enabled the first time since the terminate request will also disable the channel.

Below is example code, showing how the terminate request should be made before enabling the channel:

// Your DMA configuration code goes here
// --->
// ....
// <---
// End DMA config code

// To clear unwanted transfer requests (DRQ), issue a CPU terminate chain request
CyDmaChSetRequest(DMA_Channel, CPU_TERM_CHAIN);

// Enable the DMA channel, This enable kills the spurious DMA transaction if there is one
// and disables the channel, must re-enable
CyDmaChEnable(DMA_Channel, 1);

// re-enable the DMA channel
CyDmaChEnable(DMA_Channel, 1);

Hello,

I am working on a project with the 5LP, where I need to semi-frequently change the "settings" on an application via  PC => USB => 5LP.

These setting are simply pure numerical integer data. The hardware can completely reset to receive the new settings if necessary.

I've experimented with a  bootloader/bootloadable system,  where the bootloadable runs the whole application with whichever data settings built into it.  However this feels kinda clunky, rebuilding and programing the whole application for just some settings changed.

I was wondering what other USB setups might work better?

Thanks for any advice!

ngohara

Hi all,

I would like to create a static adc window that specifically buffers 1024 2byte-words but does not slide.

I am thinking DMA would be the most efficient way to do this.  I would have to use multiple TD's I'm assuming since the ADC_sample() only gets one 16 bit sample at a time but I need to create an array of them, but since the number of TD descriptors is limited to 128 I would have to use two sets of DMAs with a counter to determine when the one dma has fully buffered 128 2byte-words and then transfer those 128 2byte-words to a different buffer, essentially doing the second transfer 8 times.  Of course I wil have to use a counter to determine when the first DMA buffer is finished to make sure I don't grab overlapping data.  Once all of this is done I can have another counter looking at the second dma to determine when it has completed 8 transfers. 

Is this something that is achievable using the PSoC 5lp? 

If there is a better way please let me know, or if I am thinking about this wrong.

Thanks,

scarlson

Hi,

My project involves amplifying a bipolar signal and process it digital using digital lock-in amplifier.

I am particular interested to use PSOC 5 for my project. Can any one help me with the following:

1. What is the gain bandwidth of PSOC 5 Op-amp The datasheet quoted typical 8 MHz but what is the max?

2. How can I amplify my bipolar signal using the built in PGA?

3. Can I connect external components to use in conjunction of the built-in Op-Amp to amplfy my bipolar signal? If I can, how to do it?

Thanks a lot for your times and attention.

Hi all, I'm trying to create a PSoC 5LP Design and after the workspace/project is created, i cannot add any components from the component catalog into the workspace at all. By adding i mean click and drag the component into the workspace. (i'm trying to add bootloader, but every other component doesn't work either). Please help, thanks

Hello,

I am using the CY8C58LP dev module on CY8CKIT-001 board.

I am using 2 WaveDAC8's to  source/sink a  specific current waveform across a variable Rload.

(For ease of testing, Rload is a static 10k ish ohms). 

One WaveDAC8 (hereafter revered to as I_1)  is initially setup as a 60uA square wave @ 100ms period as a source.

Second WaveDAC8 (hereafter revered to as I_2)  is initially setup as a 60uA square wave @ 100ms period as a sink.

They are both source from the same 1kHz clock.

I am using the WaveDAC8's  wc1 flags as an end-of-wave  isr,  which sets a flag. When both flags are set (which happend near simultaneously)  I run some code to  switch polarities using the WaveDAC8_x_IDAC8_SetPolarity()  functions, where x is 1 and 2. 

With my oscilloscope leads directly across Rload, I should be seeing alternating +600mV/ -600mV  square waves.

However, at the moment, the 2nd wave (the attemped negative wave) is not behaving properly, instead creating a +20mV square bump.

It then switches back properly to the +600mV wave, and again back to the +20mV bump.

To me, this indicates that the WaveDAC8_x_IDAC8_SetPolarity()  alone are not enough to change the source/sink properly.

I've tried surrounding them with Stop/Start  (which made things worse by screwwing up the good wave) and with rerunning Init each time (also made things worse).

I've also tried to forget switching the polarity, and used analog demuxes to flip the orientation around the load. For some reason I haven't figured out yet, this also does not create a proper negative wave, even though the poles should be completely flipped!

So, I'm out of ideas about how to properly switch the polarities  to  create co-joined  positive negative signals.

Any advice would be truly appreciated.

Thank you

ngohara

PS: Current project should be attached. Please excuse commented code mess, though this does demonstrate both my SwitchPolarity, and my SwitchMux ideas.

Hello, 

I am planning to use a CY8C56xx  with a WaveDAC8 as current source/sink  on a  variable external load. This load includes the possibilities of becoming open or too large to power (ie  Rload * WaveDAC8_Amplitude  >   VCC- Voverhead )  and I would like to know what behavior to expect from the WaveDAC8 module during these time?

Does the WaveDAC8 include protection against these modes, and if so, what are the ranges of this protection?

Are there indicators of these faults occurring? I haven't seen any in the component documentation, but I want to verify this.

Any advice, or links to appropriate documentation, is appreciated!

ngohara

I'm using the PSoC1 as essentially a multi-channel frequency counter using 16-bit counters to count frequencies from 10kHz to 100kHz.  Hardware-wise, the Enables of the counters are tied to Vcc, and the clock/count input is tied to the frequency to be counted to allow direct pulse counting.  There is some calculation involved using the starting counter value, the ending counter value, and the number of times the counter has rolled over between samples.  The problem arises from input frequencies greater than the counter period.  On occasions where the counters rollover twice between samples, the second rollover is failing to be accounted for, leaving the final frequency count a full counter period less than its actual frequency.

I think my problem arises from the fact that I'm running the frequencies to be counted into the clocks of the counters.  I believe this limits the interrupt response time, causing the missed TC count increment.  I simply need confirmation if this is the case.