LCD via SPI, no response

[T3sl4co1l]

I'm trying to initialize this display,
http://www.ampdisplay.com/documents/pdf/AM-240320D5TOQW-T00H(R).pdf
and can't seem to get a single bit out of it.

I've literally tried everything I can, with the pins that I have.

It seems to be a RM68050 controller, which in turn seems to be a copy and slight variant ("improved", but I'm guessing it's a Taiwanese copy at best, so I use the term loosely) of the ILI9325, which some of you probably have experience with on some display or another.

I have a breakout board, on which the D0-D17 pins are grounded, and all the other signals are set to VCC/GND per the datasheet instructions for SPI mode.  (It happens to be very similar to the LPC17xx dev kit, which uses this display.)

One mode pin is terminated on the flex, not brought out to a connector: JP1.  I have changed this per instructions.

I have SCL wired to display pin 34, MOSI to pin 12, MISO to pin 10, nCS to 31, and nRST to 32.  That should be everything.

The datasheet doesn't spell it out, but I get the impression that it only responds if CS is asserted, and the first few bits shifted in match the ID bits in the header (i.e., 0x70 plus control bits).  It's not clear what it's supposed to respond with, if anything, but a read instruction is supposed to return something after a maximum of six consecutive bytes.

Just in case I've swapped bit polarity, direction or phase, I've exhaustively tested all 256 possible START bytes.  No effect, dead as a doornail.

What am I missing?

Tim

[StillTrying]

The data sheet seems to hint it needs a reset after power up ?

[Cerebus]

The data sheet seems to hint it needs a reset after power up ?

Exactly this. I have a display (literally sitting 3 inches from my left elbow) with an ILI9325 in it. I had exactly the same problem and thought I was doing everything right. I'd tied its reset pin to the output nReset from a Cortex chip which is automatically generated from the Cortex's power up circuitry. Refused to work, then one day I manually reset the board after power up and the display sprang to life. Switched its reset line to a GPIO and fired that a short while after power up and all was fine from then on.

[T3sl4co1l]

I have it set to assert nRST for ~10us, then wait 50ms before continuing.

Tim

[a59d1]

Bad hardware?

[T3sl4co1l]

The displays came from a project where they were used with parallel interface, working.  I have no particular reason to doubt that both displays I have here are in normal working order, whatever that might mean with regards to the serial interface.

Or if you mean my end, the waveforms read correctly on the 'scope.

What if the pins are just completely wrong?  Use /RD instead of /WR for SCK???  Or CS active high, or it's actually RS or something?  That would be a gross datasheet error, but I wouldn't consider that impossible...

Tim

[T3sl4co1l]

Exactly this. I have a display (literally sitting 3 inches from my left elbow) with an ILI9325 in it. I had exactly the same problem and thought I was doing everything right. I'd tied its reset pin to the output nReset from a Cortex chip which is automatically generated from the Cortex's power up circuitry. Refused to work, then one day I manually reset the board after power up and the display sprang to life. Switched its reset line to a GPIO and fired that a short while after power up and all was fine from then on.

Was this serial or parallel?

Tim

[Cerebus]

Serial, on a carrier board dedicated to using the serial interface. Note, definitely not the same display as you're using but another that uses an ILI9325 (2.8" 240x320). Had me scratching my head for days, convinced I'd done everything right until I serendipitously hit the manual reset switch instead of letting the board reset itself after flashing. 

[Cerebus]

I have it set to assert nRST for ~10us, then wait 50ms before continuing.

Tim

From the ILI9325 datasheet. Note the units.

[T3sl4co1l]

Ah, didn't look for that there.  I thought the "1ns" in the other datasheet looks awfully suspicious.

Still not getting anything though...

Edit:
Wait, I just changed it to spam the same data output six times in a row (rather than sending dummy 0's or 1's), and now I'm getting different bits.  Booting up the scope...

It's responding at "start" = 0xb8 and 0xb9, and 0xba = 0x7f (SDO is default '1') may imply it's got a misaligned clock edge... oooh, SCK is default low, that's probably throwing it off, it needs "Mode 3" by the looks of it... hey, it's responding on the "start" it's supposed to (0x71)...

It's still delayed by one byte though. Fig8-9 shows output on the byte immediately after a valid "start" byte.  What's up with that?  What registers am I actually writing to in these subsequent bytes, if any?

Thanks.

Edit:
It looks like the interface state doesn't reset when CS is deasserted.  Or even when RESET is asserted!

Example sequence:

Code: [Select]

[Power on, MCU init, LCD REST asserted for ~2ms]
SPI tx  rx
<CS low>
71h     0ffh
0h      0ffh
0h      93h
0h      25h
<CS high>
[Some time goes by]
<CS low>
71h     0ffh
0h      0ffh
0h      25h
0h      93h
<CS high>
If I, say, reprogram the MCU (so it goes through init again, and sends the 2ms reset again), the read bytes alternate again!

It also ONLY sends data when R/W bit = 1.  The diagrams show SDO shifting out data of some sort, but in actuality it's almost always set to '1'.  So it's impossible to know if it's reading what you are writing to it.

It seems like the RM68050 is incompatible with the ILI9325, despite what people say.  It seems to be all the cluster you'd expect from a Taiwanese chip...

Tim

[CJay]

I don't see any mention that you've changed the interface mode from parallel to serial on the jumpers or did I miss that somewhere?

(it may be implicit in the first message but the datasheet seems to mention a jumper as well as the DB lines etc.)

[newbrain]

[...]
Example sequence:

Code: [Select]

[Power on, MCU init, LCD REST asserted for ~2ms]
SPI tx  rx
<CS low>
71h     0ffh
0h      0ffh
0h      93h
0h      25h
<CS high>
[Some time goes by]
<CS low>
71h     0ffh
0h      0ffh
0h      25h
0h      93h
<CS high>
If I, say, reprogram the MCU (so it goes through init again, and sends the 2ms reset again), the read bytes alternate again!

It also ONLY sends data when R/W bit = 1.  The diagrams show SDO shifting out data of some sort, but in actuality it's almost always set to '1'.  So it's impossible to know if it's reading what you are writing to it.

The fact that data is sent only with R/W = 1 is stated in the DS, page 67, and not surprising.
Have you tried a more complete sequence to set the index register to 00h (ID) and then read it back?

Code: [Select]

Send:    0x70 0x00           // Write the index register to 00h, ID
Receive: ---- ----

Send:    0x71 0x00 0x00 0x00 // Read back from the set register
Receive: ---- ---- 0x93 0x25


[T3sl4co1l]

Huzzah, it works!



The breakthrough was getting anything at all out of it.  Once I got data, I was able to correct SPI framing, discover the static byte counter in the interface, figure out which operations have padding ("dummy") bytes and how many, and finally paste in some off the shelf code (came from the LPC17xx dev kit) to initialize the display.

Tim