FCDEV3B sleep mode bug update

[Mychaela Falconia]

Hello FreeCalypso community,

With April Fools silliness out of the way, I have some real news
regarding the progress of our family of projects.

The first update is that I have progressed one more step in the sleep
mode bug investigation.  With help from our dear Das Signal, I learned
how to convert one of my oscilloscope probes from the hook type to the
needle type, and I was then able to use this o'scope probe to observe
the FDP signal (Calypso output) on a decased Pirelli motherboard.  I
powered it with alligator clips on the spring contacts of the battery
connector (a total hack, but I got the clips to stay connected and not
short for the duration of the experiment), loaded an AT-over-RVTMUX
Magnetite fw build via USB and fc-xram (connect USB with no battery
power, run fc-xram, then apply power to the battery contacts), and
observed the FDP signal that comes out to an unpopulated 0402R
footprint with different AT%SLEEP settings.

The observation of this FDP signal confirmed my hypothesis: it does go
low in all sleep modes including small sleep, but stays a constant
high when all sleep modes are disabled.  Consequently, my bigger
hypothesis that having this FDP signal connected to the flash chip's
reset input is what causes the sleep mode bug (because of it going low
in all sleep modes and jerking the flash chip's reset line) is still
plausible, and is supported by the observation that on Pirelli's board
this FDP signal does NOT drive the flash reset line - that resistor is
unpopulated.

The next step will be to try a very delicate surgical experiment on an
FCDEV3B: remove the flash+pSRAM chip (BGA rework station to the
rescue), cut the trace between the D5 ball pad (flash reset) and the
microvia it goes to, make a solder bridge or some other hacky
connection to the C5 ball pad next to it (WP#/ACC input, connected to
flash Vcc through a pull-up resistor), and then put a new
S71PL129NC0HFW4B flash+pSRAM chip back on (BGA rework station once
again).  The effect will be to disconnect the flash chip's reset input
from FDP and tie it high instead.  Then see if this hw change makes
the sleep mode bug go away.  I am going to email Technotronix and ask
them if they can do the just-described feat.

The other big venture I've been doing is dealing with several
different LCD manufacturers in China, trying to find a suitable LCD
module for our FC Libre Dumbphone handset.  My display size
requirement is 176x220 pixels (color TFT), chosen for two reasons:
(1) so that the first prototype of our handset can also serve as a
replacement for TI's D-Sample, and (2) to maximize our ability to
reuse TI's existing starting-point UI code that is written for this
display size.  The second requirement after the size is that the
interface needs to be 16-bit parallel (as opposed to 8-bit parallel or
SPI, which are the other common options in the industry); this
requirement is driven by performance considerations: both the D-Sample
and the Pirelli have 16-bit LCDs, wired such that each RGB565 pixel is
sent to the display with a single Calypso ARM7 write cycle, and I am
not comfortable with using a slower LCD interface in our own design.
The third and final requirement is that the LCD needs to be designed
for 6 o'clock viewing direction, as that is the direction from which
the display on a cellphone handset is going to be viewed.

I used to be a big fan of Crystalfontz, a USA-based distributor of LCD
modules who generally have good technical documentation for their LCDs
and offer all of their products in a hobbyist-friendly manner with no
MOQs, but their 176x220 module only brings out 8 data lines; the
actual controller in their LCD is 16-bit-capable, but only 8 lines are
brought out to the FPC tail.  I asked them if they could make a
modified version with all 16 lines brought out, and they responded
with a price figure that is not reasonable for our little project.  So
I went to Alibaba (the Chinese market) and found that quite a few of
those Chinese manufacturers already have 176x220 pix 2" TFT LCD
modules that bring out all 16 data lines plus the IM0 configuration
pin, so the LCD can be used in either 8-bit or 16-bit mode.

The big difficulty is that the details of the LCD interface (whether
the FPC tail is soldered down or goes into a ZIF connector, and the
exact pinout of this connector or solder-down tail) are different for
each manufacturer's LCD module, not standardized in any way.  It is
therefore not possible to design a handset motherboard to accept "any"
LCD module and let various manufacturers compete for our business at
some far future date when we go into volume production, instead we
have to design our motherboard for some specific LCD module XYZ from
manufacturer ABC from the start.  Changing to a different LCD module
from a different manuf further down the line (for example, if our
originally chosen vendor goes out of business or starts demanding an
unreasonably high MOQ*unit_price product) will be possible, but will
require a costly respin of the motherboard.

And how exactly does one choose a specific LCD module XYZ from manuf
ABC when there are some 10 or 20 different LCD manufs trying to get
our business?  (Yes, that is how the Chinese market works - post an
RFQ on Alibaba and get flooded with product offers.)  What I've done
so far is that I selected 3 vendors for further evaluation based on
the datasheets they sent me, and I have ordered sample pieces for
evaluation from all 3 of them.

One of these 3 vendors unfortunately turned out to be rather sleazy:
their original datasheet said 6:00 viewing direction, but now the guy
is telling me that the samples pieces they sent me are for 12:00
viewing direction and that they will make the 6:00 version when we go
into volume production.  I told him that he and his company are NOT
going to get our business unless they send me evaluation samples
(*before* we commit to them as our vendor of choice) with the
polarizer film put on for the 6:00 viewing direction (NOT the 12:00
direction which seems to be the industry's favorite for some reason
beyond my understanding); I haven't heard back from him yet, but I am
already refocusing my attention on the other two vendors' modules I've
selected for evaluation.  Vendor 2 seems to be in the process of
preparing the shipment of their sample pieces, and I haven't heard any
shipping updates from vendor 3 yet.

Once I actually receive some LCD samples in my hands (at least one of
the vendors already shipped theirs, tracking says I am supposed to get
them tomorrow, but it's the one with the wrong viewing direction), my
plan for testing them is to connect each LCD under test to an FT2232D
adapter in the MCU host bus emulation mode - this FTDI mode emulates
an 8-bit microprocessor bus and can be used to drive a parallel
MCU-style LCD in 8-bit mode.  Then write a Linux PC host program to
program the LCD controller and display test pictures by talking to the
MCU-host-bus-emulating FT2232D via libftdi.

One of the 3 LCD vendors I've been dealing with said they would
include a breakout board with their LCD samples that brings all of the
LCD module's signals to header pins; if I actually receive the samples
from this particular vendor and if there is indeed a fitting breakout
board included, I will test that vendor's LCD first, using their
breakout board, one of our existing FT2232D breakout boards and some
hacky breadboard to make those connections that aren't straight 1-to-1.
Otherwise I may have to design and build a special LCD test board,
which was my original plan before one of the 3 vendors dropped the
12 o'clock surprise on me.  All in all, a huge mess, but it needs to
be done.

Hasta la Victoria, Siempre,
Mychaela aka The Mother