You have met all the conditions for the applicable mode in this
I'm using Single Sample mode. The Amux Start function is called in the beginning of the program, and the AMux_Next is called to connect the first channel to the ADC_DelSig.
A subroutine starts a conversion and the ADC is polled for conversion complete, the sample is collected, the AMux moves to the next channel. The program makes a pass through the main loop before the next conversion is initiated, which should allow plenty of time for the AMux to connect to the next channel.
I really don't have a problem when connecting directly to the ADC_DelSig and was wondering if there are any known issues with the AMux schematic part.
Did you set your ADC to "Multi-Sample" mode or "Single Sample"? The latter may lead to an error when timing is not as requred. See datasheet for "Modes" on pg. 5
This looks like it might be a Keil issue. What I thought was a MUX problem appears to be a heap space issue. I have a module called 'public.c' where I declare all my variables. To debug this problem I went back to a saved version that worked and began slowly adding the new code in and testing. I bundled the current work space, when to lunch, came back and added only one UINT16 variable and the problem came back, as though the memory is being stepped on. I removed the variable but the problem go away. I unzipped the version before adding that one variable, reprogrammed the part and no problem.
Do you know if you are supposed to group your global variables by size to keep things easier to deal with?
Could I be having an issue with a Build setting? The optimization is level 4, optimizing for Size.
Any suggestions and or, what do most people use? I've never changed it from the default settings.
Is there are preference for how heap variables are listed to perhaps avoid byte boundary issues or a compiler setting that addresses that? I moved the UINT16 variable in the module where it was replaced to be adjacent to the UINT16 values that were getting stomped on and it appeared to fix the problem.
My UINT16 variables that were getting messed with contain the result of ADC readings that are updated regularly. This caused me to start questioning the ADC and the AMux but I don't believe those are the root cause as they have been working fine from Creator 1.0, 1.01, 2.2 and now 3.0.
My ADC readings are in error when my program begins. If I implement a delay, it solves the problem.
The way I use the ADC connected to an AMUX is to start a conversion, then poll the conversion complete flag before reading the result. This doesn't appear to allow enough time for the ADC data to be stable. After a period of time of errant readings, I do a one second delay, the readings become valid and the problem doesn't return. I can reproduce the problem consistently.
My solution was to put in a CyDelayUs(20) after the call to the ADC routine. I then abandon the delay after the first 2 minutes of operation to speed the main loop back up. I feel like my solution is a voodoo dance.
Does anyone have some insight about errant ADC readings? I'm using Creator 3.0 on a PSoC 3.
Nick, I would file a CASE on this, point to this thread.
Just a thought.
To create a technical case at Cypress -
“Create a Case”
You have to be registered on Cypress web site first.
Yes, I opened a thread 8/13/14.
The problem I am having is readings from the ADC when the program first begins running. It's as if it is stuck in some state because once I put in a one second delay, it rights itself and runs fine, full speed ahead. Not understanding the problem I have had to allow a small amount of time between the ADC indicating that a conversion is complete and actually retrieving the data. That works across the board.