1) Start the isr ?
2) Start Comparator ?
3) Set ISR, if set to level you cleared interrupt in isr routine.
4) Bias comparator properly ?
5) Offset input rectifiled 60 Hz so its in the allowed analog input range of the comparator ?
6) Set address of isr if C isr.
Maybe post archive of project -
Use Firefox or IE, not chrome to post.
For debugging, you can route the comparator output to a pin, and check with a scope (or logic tester) whether you get a proper signal there.
I would guess its either wrong compare value (0V probably wouldn't work), a not started component, or disabled global interrupts.
Dana, I think none of your reasons can be applied to my situation. I've already configured all things properly. Hli, my comparator detects 0V quite well(actually it a little bit higher than 0V) but it seems the rising edge of comparator output cannot trigger the interrupt service routine. I'm currently using the PSoC's comparator.
1. I assumed that you had observed the comparator does changes state.
2. Did you check if there is only "ONE" changed of state from the comapartor output near your trigger point?
3. Did you check if the circuit works when the clock is lower say 10m or 5m?
Since your program does more than just checking for that interrupt: can you create a reduced example that just employs the comparator (and the VDAC used for setting the reference), and maybe the one pin the gets driven by the comparator output? The ISR then could toggle a LED.
That way you can ensure that it really is a problem with the ISR and the comparator, and not something else in your project. And it makes looking for the problem easier for us...
You have the comparator setup for 212 mV trip (+ a little hysterisis).
Which seems OK. What looked odd to me is clocking the comparator
at 60 Mhz, when its response time is more like < 10 Mhz. Yet I could
not find any AC spec on Comp clock. Suspicious in my mind. Plus
thats a waste of power in light of 60 Hz signal of interest.
Another consideration, if you overdrive a comparator it takes additional
recovery time to get it back in operation, although I do not think that is
a factor at 60 Hz. What is the input voltage range of the sine wave, and
with respect to ground ? The input signal should not go below Vssa.
I presume you see "normal" output of comparator tripping on the 60 Hz ?
One other thought, if you take an input to a comparator or OpAmp
outside its CM range, depending on architecture, you can get phase
reversal in the output as one possibility. Generally not a latchup condition,
eg. once input returns inside CM range comparator out reports correct
Also I do not think you need to synch comparator as its only driving an
Lastly I noticed you are not using Creator 3.0, give serious consideration to
updating as each version of Creator includes bug fixes. Note I am getting a setup time
warning in build that should be cleared up.
Hi, I did the following -
1) Used a 256 mV Vref for comparator
2) Usede WaveDAC8 to creat a sine for testing
3) Modified variables used in ISR to be volatile
4) Eliminated synch of comparator (I dont think you need it)
Seems to work. You have a setup time warning I think you should take care of.
Thank you, Dana.
I've confirmed that your project works well.
However, when I input the real, recitified, voltage-divided sine wave to the comparator, the control register always outputs "HIGH".
In this case, I've observed the comparator outputs pulse as its input was connected to the WDAC8, but the ISR still does not work well.
Anyway, I really appreciate your help and I think I should report this problem to Cypress.
Oh my god!
I finally succeed to fix my problem.
It was the parameter of the function ADC_SAR_IsEndConversion.
Since I set the parameter as ADC_SAR_WAIT_FOR_RESULT, the cpu of PSoC was stuck on the function block.
By changing the parameter to ADC_SAR_RETURN_STATUS, I could fix the problem.
Thanks to all people who replied my silly problem.
So the ISR did work fine, and just the code in the mail loop did not read the results correctly? That's why reducing the problem to the most simple example is so important during debugging :)
Nice to hear that your problem is fixed.
But would your software locked up waiting for the signal? then the older version of software should had stopped working completely.