Touch screen PENIRQ problems with AD7843

Greetings fellow embedded systems colleagues -

I have a new Atmel ARM9 based design, connected to an AD7843 touch 
screen controller. The problem is the !PENIRQ line *NEVER* changes state 
when the panel is pressed. Looking at it on an analog scope, it never 
even tries to budge. If it were a pullup/pulldown issue, I would fully 
expect it to come down at least a little from the 3.3 volt rail, but it 
just stays steady the whole time.

I'd like to talk to someone who has some experience with the AD7843 and 
see what I'm missing. To date, we have done the following:

* Ensured the !PENIRQ is connected to the CPU and to the AD7843 (we can 
wiggle it when set to an output, and can see that it gets driven low 
when we manually ground it)

* Used small (50kohm) and large (100kohm) pullup resistors on the 
!PENIRQ line

* Tried setting PD to 00 and 10, which SHOULD enable !PENIRQ's operation

* Verified that we can read both the X and Y axis on the touch screen 
(this works perfectly!) - we get all 12 bits of precision on both axes.

* Serial/differential mode makes no difference

* Running SPI bus at 4Mhz, 2Mhz, and 1Mhz (even bit banging it at a 
<100khz rate) - no !PENIRQ when touched

* We are reading the !PENIRQ line prior to asserting chip select, just 
so the read conversion doesn't cause !PENIRQ to be cleared before it's read.

* Swapped out the part just in case the AD7843 got torched - no change

* Have looked at the TI, Analog Devices, and a few other data sheets, 
have downloaded dozens of manuals and example programs - all of which 
seem to indicate it'll assert !PENIRQ simply by setting PD to 00 or 10. 
Our init sequence matched a Linux and Windows CE device driver, so I'm 
sure we're doing it right.

Does anyone have any clues as to why this might be occurring? It's 
obviously something simple, but we can't figure out what! In the mean 
time, we have some old 3rd party devices that have the AD7843 in them 
and we're going to examine its behavior, but in the mean time if anyone 
has any hints or suggestions, it would be most appreciated.

Thanks!

-->Neil

On Apr 29, 12:14=A0am, Neil Bradley <nb_no_s...@synthcom.com> wrote:
> I have a new Atmel ARM9 based design, connected to an AD7843 touch
> screen controller. The problem is the !PENIRQ line *NEVER* changes state
> when the panel is pressed. Looking at it on an analog scope, it never
> even tries to budge. If it were a pullup/pulldown issue, I would fully
> expect it to come down at least a little from the 3.3 volt rail, but it
> just stays steady the whole time.
>
> I'd like to talk to someone who has some experience with the AD7843 and
> see what I'm missing. To date, we have done the following:
>
> * Ensured the !PENIRQ is connected to the CPU and to the AD7843 (we can
> wiggle it when set to an output, and can see that it gets driven low
> when we manually ground it)
>
> * Used small (50kohm) and large (100kohm) pullup resistors on the
> !PENIRQ line
>
> * Tried setting PD to 00 and 10, which SHOULD enable !PENIRQ's operation
>
> * Verified that we can read both the X and Y axis on the touch screen
> (this works perfectly!) - we get all 12 bits of precision on both axes.
>
> * Serial/differential mode makes no difference
>
> * Running SPI bus at 4Mhz, 2Mhz, and 1Mhz (even bit banging it at a
> <100khz rate) - no !PENIRQ when touched
>
> * We are reading the !PENIRQ line prior to asserting chip select, just
> so the read conversion doesn't cause !PENIRQ to be cleared before it's rea=
d.
>
> * Swapped out the part just in case the AD7843 got torched - no change
>
> * Have looked at the TI, Analog Devices, and a few other data sheets,
> have downloaded dozens of manuals and example programs - all of which
> seem to indicate it'll assert !PENIRQ simply by setting PD to 00 or 10.
> Our init sequence matched a Linux and Windows CE device driver, so I'm
> sure we're doing it right.
>
> Does anyone have any clues as to why this might be occurring? It's
> obviously something simple, but we can't figure out what! In the mean
> time, we have some old 3rd party devices that have the AD7843 in them
> and we're going to examine its behavior, but in the mean time if anyone
> has any hints or suggestions, it would be most appreciated.

Since you can't seem to determine if it's a software or hardware
issue,
you should try a simple test:
1. Remove any code that would cause the AD7843 chip-select to be
asserted.
2. Ensure the microcontroller pin connected PENIRQ is configured as
input.
3. Monitor the PENIRQ line with a 'scope while touching the touch
screen.

If the PENIRQ line still remains high, it is most likely a hardware
issue.
If it goes low (my guess), it is most likely a software issue.

Dingo wrote:
>> Does anyone have any clues as to why this might be occurring? It's
>> obviously something simple, but we can't figure out what! In the mean
>> time, we have some old 3rd party devices that have the AD7843 in them
>> and we're going to examine its behavior, but in the mean time if anyone
>> has any hints or suggestions, it would be most appreciated.
> Since you can't seem to determine if it's a software or hardware
> issue,
> you should try a simple test:
> 1. Remove any code that would cause the AD7843 chip-select to be
> asserted.

Thanks for the reply, Dingo.

The AD7843 needs to be programmed up to drive the PENIRQ, and I 
mentioned before that I had tried both possible settings for it. Not 
allowing !CS would surely make PENIRQ not work. Plus, the code doesn't 
poll the 7843 unless PENIRQ gets asserted anyway.

> 2. Ensure the microcontroller pin connected PENIRQ is configured as
> input.

Yeah, already did that:

 >* Ensured the !PENIRQ is connected to the CPU and to the AD7843 (we can
 > wiggle it when set to an output, and can see that it gets driven low
 > when we manually ground it)

We know the line works.

> 3. Monitor the PENIRQ line with a 'scope while touching the touch
> screen.

Did that, too (that's how we'd know if the signal dipped or not), 
including triggers. We could manually cause the scope to trigger if we 
grounded the pin.

The real problem is the AD7843 is just flatly not pulling the pin low. 
We've also disconnected the 7843 from the CPU just in case there was 
some oddball backpowering going on, and it had no effect, either.

-->Neil

On Apr 29, 3:55=A0pm, Neil Bradley <nb_no_s...@synthcom.com> wrote:
> Dingo wrote:
> >> Does anyone have any clues as to why this might be occurring? It's
> >> obviously something simple, but we can't figure out what! In the mean
> >> time, we have some old 3rd party devices that have the AD7843 in them
> >> and we're going to examine its behavior, but in the mean time if anyone=

> >> has any hints or suggestions, it would be most appreciated.
> > Since you can't seem to determine if it's a software or hardware
> > issue,
> > you should try a simple test:
> > 1. Remove any code that would cause the AD7843 chip-select to be
> > asserted.
>
> Thanks for the reply, Dingo.
>
> The AD7843 needs to be programmed up to drive the PENIRQ, and I
> mentioned before that I had tried both possible settings for it. Not
> allowing !CS would surely make PENIRQ not work. Plus, the code doesn't
> poll the 7843 unless PENIRQ gets asserted anyway.
>
=46rom the datasheet: "On power-up, PD0 defaults to 0,
while PD1 defaults to 1."

And: "This configuration results in keeping the AD7843
permanently powered up with PENIRQ enabled."

So PENIRQ is automatically enabled at power-up.

I think it would be quite valuable to test the behavior
of PENIRQ before software configures the AD7843.

Dingo wrote:
>>> you should try a simple test:
>>> 1. Remove any code that would cause the AD7843 chip-select to be
>>> asserted.
>> Thanks for the reply, Dingo.
>> The AD7843 needs to be programmed up to drive the PENIRQ, and I
>> mentioned before that I had tried both possible settings for it. Not
>> allowing !CS would surely make PENIRQ not work. Plus, the code doesn't
>> poll the 7843 unless PENIRQ gets asserted anyway.
> From the datasheet: "On power-up, PD0 defaults to 0,
> while PD1 defaults to 1."
> And: "This configuration results in keeping the AD7843
> permanently powered up with PENIRQ enabled."
> 
> So PENIRQ is automatically enabled at power-up.
> 
> I think it would be quite valuable to test the behavior
> of PENIRQ before software configures the AD7843.

You know, I'm from the school of always initializing everything so it 
starts to a known state. In all my testing, I never thought to try this, 
but that makes a LOT of sense.

Dingo, you are the man. Thanks for the friendly nudge. It's possible 
that the initial SPI traffic is screwed up, like CPOL or whatever is 
half a phase off, and the command I'm sending to the chip isn't really 
what I think it is.

Will let you know... thanks again!

-->Neil

In article <tsbSj.3025$5X.261@trndny08>, nb_no_spam@synthcom.com says...
> Dingo wrote:
> >>> you should try a simple test:
> >>> 1. Remove any code that would cause the AD7843 chip-select to be
> >>> asserted.
> >> Thanks for the reply, Dingo.
> >> The AD7843 needs to be programmed up to drive the PENIRQ, and I
> >> mentioned before that I had tried both possible settings for it. Not
> >> allowing !CS would surely make PENIRQ not work. Plus, the code doesn't
> >> poll the 7843 unless PENIRQ gets asserted anyway.
> > From the datasheet: "On power-up, PD0 defaults to 0,
> > while PD1 defaults to 1."
> > And: "This configuration results in keeping the AD7843
> > permanently powered up with PENIRQ enabled."
> > 
> > So PENIRQ is automatically enabled at power-up.
> > 
> > I think it would be quite valuable to test the behavior
> > of PENIRQ before software configures the AD7843.
> 
> You know, I'm from the school of always initializing everything so it 
> starts to a known state. In all my testing, I never thought to try this, 
> but that makes a LOT of sense.
> 
> Dingo, you are the man. Thanks for the friendly nudge. It's possible 
> that the initial SPI traffic is screwed up, like CPOL or whatever is 
> half a phase off, and the command I'm sending to the chip isn't really 
> what I think it is.
> 
> Will let you know... thanks again!
> 
> -->Neil

I just perused the AD7843 datasheet; according to the 2nd paragraph on 
page 19, PENIRQ is enabled by default on power-up, so it is almost 
certain that your first write to the device is clobbering PD0/1, likely 
due to an SPI phase mismatch.

I just had this happen to me with an Analog Devices ADC; reading of the 
SPI timing diagrams implied a particular phase/polarity; the device only 
worked when I reversed them.

--Gene

"Gene S. Berkowitz" <first.last@verizon.net> wrote in message
news:MPG.2288030d2916d2a989910@news.verizon.net...
> In article <tsbSj.3025$5X.261@trndny08>, nb_no_spam@synthcom.com says...
> > Dingo wrote:
> > >>> you should try a simple test:
> > >>> 1. Remove any code that would cause the AD7843 chip-select to be
> > >>> asserted.
> > >> Thanks for the reply, Dingo.
> > >> The AD7843 needs to be programmed up to drive the PENIRQ, and I
....
> > > I think it would be quite valuable to test the behavior
> > > of PENIRQ before software configures the AD7843.
> >
> > You know, I'm from the school of always initializing everything so it
> > starts to a known state. In all my testing, I never thought to try this,
> > but that makes a LOT of sense.
> >
> > Dingo, you are the man. Thanks for the friendly nudge. It's possible
> > that the initial SPI traffic is screwed up, like CPOL or whatever is
> > half a phase off, and the command I'm sending to the chip isn't really
> > what I think it is.
> >
> > Will let you know... thanks again!
> >
> I just perused the AD7843 datasheet; according to the 2nd paragraph on
> page 19, PENIRQ is enabled by default on power-up, so it is almost
> certain that your first write to the device is clobbering PD0/1, likely
> due to an SPI phase mismatch.
>
> I just had this happen to me with an Analog Devices ADC; reading of the
> SPI timing diagrams implied a particular phase/polarity; the device only
> worked when I reversed them.

Datasheets don't you just love them.

My current favourite is a NXP/Philips data sheets that goes on about
two types of input to the device being straight digital and schmitt input
with different characteristics. NOWHERE in the data sheet does it specify
WHICH inputs are which type! Search for schmitt in the datasheet only
gives the input definition (electrically).

NXP support gives glib answers and still has no answer months later!

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate