Consider posting your project. I have used the component a number of times in last month,
consistently get correct results.
“Create Workspace Bundle”
Built and attached a template project based on the CY8CKIT-059.
It is set for 17.8KHz and is clearly running at 8.9KHz. It's using an iSource 0-2mA output; I'm using a 1k resistor to ground, P3.
Thank you kindly for taking a look at it. The project I'm working on needs to be able to run in the high audio frequencies at the best resolution possible, so hopefully this is fixable.
I do have a 32768Hz crystal connected, which shouldn't make any difference. It's only being used to drive a heartbeat interrupt routine.
You are returnig from main() to... to where??? I would suggest to put an infinite loop at the end, it might be that the chip gets re-initialized otherwise.
I can do that, but I've never had a problem with much more complex projects so far. This technique gives full CPU to servicing interrupts which is something that would appear the WaveDAC8 component needs, though it does most of its work using DMA.
When I use a buffered VDAC 0-4V, the frequency is spot-on, but the resolution is pretty poor at 17.8KHz. Resolution is better with VDAC 0-1V and frequency is also accurate. There's got to be some sort of divider error in the component setup when using the higher speed IDAC drive. Guess I'll have to tear into the raw component and build it from scratch manually. Unless someone knows a better way...?
There's definitely something funcky going on with the IDAC drive. I'm set for 6000 kSPS and when I up the BUS_CLK from 48MHz to 66MHz (still evenly divisible by six), I get a different frequency output from the WaveDAC8 component.
With the BUS_CLK pushed all the way to 75MHz and the sampling set to 5000 kSPS, still no joy.
F = Sample Rate / # Samples, so the resolution in time is directly affected by Rate and inversely
affected by table size. In the case of the 059 board the target clocks are all internal with their
accuracy. Unless you modified board to use precision xtal. The resolution in V is limited by the
8 bit res of the VDAC used.
From datasheet -
Actual Rate (kSPS)
This read-only field displays the actual calculated sample frequency rate. This may vary from the
requested sample rate depending on the ability to create the clock based on the integer division
of a higher frequency clock in the system.
You also have the uncertainty of the DMA bus mastering two waveforms, or other DMA operations.
Take this simple project, put a 1k resistor between P3 and GND. Then connect a scope and notice the output frequency. It will not match what the WaveDAC8 component says it should, even though the sampling rates are exact. Something is not correct inside the WaveDAC8 component when using the IDAC output drive. It's as though the sampling rate is tied to the wrong clock.
If there is an issue of the DMA being able to keep up, then the sampling rate probably needs to be capped much lower than 6000 kSPS. I'm not able to see this from the scope trace. The output appears to be a clean sine wave.
In reference to the infinite loop at the end of main(), like a for(;;), you understand that
when main() is returned from there is no guarantee where the processor program counter
goes to, the address just after the init /startup code, and could wind up fetching a non sensical
instruction, there is no code to return to. Basically blows up. So typically inside main()
is a looping mechanism to repeat the functionality in main() on an ongoing basis. Its
your highest level thread.
Your init code could recursively call main(), but your stack would probably blow up after
a few iterations due to memory fragmentation.
Noted and corrected from the last archive I uploaded, however the WaveDAC8 still outputs a frequency of 15.77KHz even though it is set to 17.79KHz. The actual and sample rate are both at 5000 kSPS and the WaveDAC8 clock shows a divider of 15 to get 5MHz from the 75MHz BUS_CLK.
When I drop down to the next actual rate of 4687.5, then the frequency becomes accurate again.
The IMO spec at 75 Mhz is +/- 7%.
I set up one with a -050 board, 65 Mhz, got a clock out at 65.221 Mhz, samples 250,
sample rate 5K, external clock for WaveDAC and got 17.791 Khz. Should have gotten
very close to 20 Khz.
I will file a CASE on this as my numbers not right either.
Thank you Dana.
I can work around this for the moment by keeping the sample rate down. I'll just put a note to be on the lookout for an updated WaveDAC8 component in the future to allow full range accuracy.
I have looked at this some more, and filed a CASE.
My past experience was with 1 - 2 Khz, accuracy looked good, etc.. But seems
when we elevate into the 10's of Khz something screwing up. Also I noticed the limit
on sample rate clock for WaveDAC in configurator is 6 Mhz, but datasheet says 8 Mhz.
I have reported this. Soon as I get some answers I will update post.
When the sampling rate is set somewhere between 4000 and 5000 kSPS, that's when things go wonky. And since you are capped from going anywhere near this fast with the VDAC output, probably explains why this hasn't been reported yet--guessing that is what most people use.
For what I'm doing with a PLL/VCO BUS-sync'd clock that is going to drive my WaveDAC8, I'm pretty sure I'll need sampling in the 3000 to 6000 (4000 to 8000 would be even better) range. I haven't yet tried driving the WaveDAC8 with an external clock source, but I am curious as to whether this issue shows up with such a dynamic/runtime change or not. I've only used fixed settings so far, which is how I found this, while determining my boundary conditions.
Anyway, good that you can actually see what I see. I dug through the WaveDAC8 component code a bit, but haven't spotted anything that stands out as the culprit. There are a couple of lines with bit shifting, I'm suspicious about. I'll need to become more familiar with those registers first before I can say yes or no.
Here is what I got back from Tech Support -
I took a closer look at the problem and was able to reproduce your issue. The limitation on the WaveDAC8 component's sampling rate is not because of the IDAC's settling time but rather due to the number of cycles required by the DMA to transfer the data to the IDAC data register from memory. Thus, faster bus clocks will allow for higher sampling rates. You can test this by dropping the bus clock in your project and you will observe that the resultant frequency drops even lower. This is not clear in the documentation as it mentions that the maximum sampling rate is 6 MSPS for Current Mode but does not specify that an 80MHz PSoC device is required to achieve such sampling rates.
I will file a change request for the documentation, thank you for bringing this to our attention.