Problem trying to use ADC1 and Touchscreen library at the same time

Hi Amit

Do you know what could be doing that?

I let you some screenshots

This is after initialize the touch library

As you can see the register has the value of 0x6

After some Go/Pause:

Some times the value is 0x5 and another is 0x6 and this is from the hello_widget example.

If you can suggest me more ideas it will be great, by the moment I'll keep doing some tests

Regards

Hi Amit

Yes it keeps doing that, maybe is a mistake on IAR, maybe the hardware breakpoint is not well implemented on IAR, actually sometimes I get some strangers errors, I don't know if the debugger is bad implemented on the IAR (I don't know a lot about the matter), but well thats a complete different subject.

If I run the code, IAR stops just after the call to function ROM_ADCSequenceConfigure(); and the register has a value of 0x6

In the next images I put I break point in the call to the function that wrights to the register and after call it, the value of the register doesn't changes at all.

After call the function you can see that the register doesn't changes

I don't know if it is an IAR error, I'm gonna try with CCS again, although I don't like it at all.

Hi Amit

I put the hardware watchpoint in CCS:

The program stops at ROM_ADCIntEnable(ADC0_BASE, 3); like you can see in the image, then never stops again.

Also I pause the program to see the value of the ADCEMUX register and always is 5, even after severals pause/resume always is five, not like IAR that sometimes changes to 6.

Regards

Hi Juan,

Perhaps the trouble (reading error message) may be from not processing interrupts during debug:
While in Debug: click view/other/debug/ select control panel. On the added control panel check the auto run launch tab has unchecked (interrupts are disabled during run) and maybe try single stepping break points, your choice.

Hi cb1

I follow your advice of see the ADC read of the touchscree in the TI's libraries and I found some interesting things, thanks.

BP101 said:

Perhaps a data overflow is occurring in the touch screen (DDA) XY coordinate plane?

May I - w/long experience w/such Touch Screens - comment, "Extremely Unlikely!"

Here's why - we must assume poster uses or has followed - this vendor's design guide.   The voltage presented sequentially to each axis is MOST UNLIKELY to exceed the ADC's "max Vin" - as that would prove injurious to the MCU's ADC.    Thus - it is without ANY merit to introduce such, "Over-Voltage!"   Further - do we even know how this MCU responds - to an, "Out of Spec, Over-Voltage introduction, to the ADC?"   (Your post argues for an apparent ADC, "wrap" upon over-voltage - yet you present NO/ZERO evidence in support of your theory.)   That's a "reach" - is it not?

The detailed diagnostic post - presented just prior to this unexplained/unjustified, "REACH" (overflow) - is far more likely to yield insight & lead to success.

BP101 said:

it would seem to me the TScreen might expect 1Msps clock rate not 2Msps clock rate. One has to look at all angles all possibilities

Why would TScreen expect 1Msps clock?   Poster clearly reported total success upon one Touch Axis - it (of course) succeeded w/2Msps clock!   You appear to have missed this key fact - did you not?    Critical reading IS important.

Look at ALL Angles.   Really?   When a clear, direct, diagnostic process is at one's doorstep?   Hardly.

"Reach" is rarely - if ever - the way...   And looking at all angles is exhausting - even counter-productive - and most always (when the scope of the issue is so small) - NOT required!

>Poster clearly reported total success upon one Touch Axis - it (of course) succeeded w/2Msps clock!
 

Perhaps you missed it was the widget example and that assumes widget example ADC clock is set also to 30Mhz. Again found it odd one axis (variable) in the Tscreen widget posters source locks up upon having an 6096 bit sample ceiling.  So the question was not unfounded in the context being given below as the sample FIFO might easily overflow the array axis variable during reads. As you know interrupt handlers are know killers if code gremlins lead to dysfunction, stack blow up etc..

The X value always stay in low values close to zero while the Y value changes from low values to values near to 4000 (I guess that the limit of the 4096 value of the ADC). This happens just with my code, when I run the hello_widget example I can see how both values changes from almost zero to almost 4000, and the values increase when I go down and to the left respectively. In my code just the Y value increase, the X value remains almost zero no matter the position of my finger.

Are you asking all here to believe that the Touch hardware & software cannot successfully read the X Axis?    Can that (really) be possible?   And passed all of this time - w/out user notice and squawk?    

It should prove useful for anyone encountering this issue to temporarily "break" the factory/existing connections to the TouchScreen.    Applying 3V3 potential to one axis - while touching the screen - should enable a simple DVM to reveal the voltage upon the 2nd axis.   By changing the location of "touch" that voltage should vary.

Your final paragraph is most confusing,  you write, "I can see how both values changes from almost zero to almost 4000, and the values increase when I go down and to the left respectively. In my code just the Y value increase, the X value remains almost zero no matter the position of my finger."

How can you claim: "both values change from almost 0 to 4000" and in the next sentence claim: "the X value remains almost zero?"

It is good that you've retreated from your (earlier/incorrect) overflow "reach."  

Hello everyone.

I solved my problem. The issue was that in my ADC initialization I was using the functions ROM_SysCtlPeripheralDisable(SYSCTL_PERIPH_GPIOE); ROM_SysCtlPeripheralReset(SYSCTL_PERIPH_GPIOE); this was causing the problem because the touch uses one pin of the PORT E in analog mode, so first I initialize the touch functionality with the TI's functions where that pin is configured, then I initialize the ADC where I call to the function I mention, reading the User's Guide I realize that PE7 is used and have an special note that says:

Note: The analog input PE7 (AIN21) is under commit control and extra steps are required in software to enable the function of the pin to be changed, see the "Commit Control" section of the datasheet for more information and the software steps required to enable proper operation of the touch screen.

So when I disable and reset the PORT E I'm changing the configuration of the PE7 use in the touch control and in specific to the control of the X axis. When I comment those two functions everything works fine.

Best regards, Juan.

Hi Juan,

Great detective work and most did suspected interference in ADC sequencer as you discovered and later reported. Must say did find it odd source disabled GPIO peripheral prior to enabling. Most often it ends up the wrong ADC channel being input or configuration overwrite in your case. Had similar issue incorrect sample data for over 2 months was actually input yet software filtering made observation difficult and obscure. You discovered and targeted the most obvious area for X-axis failure, concentrated observation found the culprit.  

Previously reviewed new TI touch screen and wondered how difficult it might be to integrate into existing applications without the RTOS.

Have any ideas or suggestions? 

cb1 said:

It may be that you are not applying full (or any) voltage to the failing axis - or that the signal IS there - but mis-routed or swallowed by other (unwanted) circuit elements/connections/software alterations!

Your issue WAS previously identified.   (as the far earlier quote reveals)

That said - you DID report that "individually" each ADC Touch Axis DID WORK.   As we must assume that PE7 was "equally victimized" then too - this mystery may not have been fully solved.

One suspects a "Green Verify" was earned by the post which arrived: Thu, Oct 13, 6:02 PM!   That post was "Liked" by you - yet NOT rightfully rewarded!