FCDEV3B V2 new thoughts

[Mychaela Falconia]

Hello FC community,

I have had an off-list discussion with someone who might be able to
help with getting FCDEV3B V2 boards made (don't hold your breath,
though, nothing is certain yet), and I have been going over the
technical details once more with a fine-toothed comb.

TL;DR version: I just reviewed the flash datasheet more closely and
realized that my FCDEV3B V2 PCB design which I thought was good and
complete (the one that already exists in the form of Altium and Gerber
files) is NOT good after all, and we need to change it once more
before we spend the big bucks (~4 kUSD) to get the new boards fabbed.

Background: let's begin by looking at the datasheets for our flash+RAM
chip:

ftp://ftp.freecalypso.org/pub/GSM/Pirelli/chips/S29PL-N.pdf
ftp://ftp.freecalypso.org/pub/GSM/Pirelli/chips/S71PL-N.pdf

The first PDF is the datasheet for the flash part; the second PDF
describes the MCP as a whole, but refers to the first one for details
regarding the flash part.  I was never able to find any documentation
for the pSRAM part, but we haven't had any problems with that part so
far.

In the FCDEV3B V2 PCB design files as they stand today the flash reset
line has a fixed pull-up to the flash power supply rail, i.e., the
active-low reset signal will never be asserted at all.  I reasoned
that this approach would be good because:

1) Many parallel NOR flash chips (for example, the classic Am29LV040B
which was once very popular for systems with socketed flash) don't
have dedicated hardware reset pins at all, and instead rely on a
built-in power-on reset circuit that ensures that the chip comes up
in the "read array" mode on power-up.

2) If you look at the table in section 11.7.2 on page 58 of S29PL-N.pdf,
you will see that the idle power consumption is actually *less* when
the chip is *not* held down in reset: compare Icc3 vs. Icc4 current
specs.  Thus not only is there no advantage to putting the flash chip
into reset during sleep (as appears to have been TI's intent), but it
actually makes the sleep mode current draw a little worse.

Based on the above two reasons, I thought that it would be best to
just pull or tie the reset line high and have it never pulse low at
all.  However, this whole time I was still a little nervous about this
idea, as I never found any wording in the datasheet that explicitly
states whether or not it is OK to not use the hardware reset line at
all.  But upon a more thorough review today, I found section 11.6 on
page 56 (same PDF), and the table and drawing given therein indicate
that on power-up, there needs to be a minimum of 250 us between Vcc
reaching the operating voltage level and the reset input going high.
In other words, the datasheet is saying that the reset input needs to
be low for the first 250 us after application of power.  This
specification gives me the impression that this chip may NOT have the
built-in power-on reset circuit like the other chips I worked with in
the past, and that it may indeed require an external reset on power-up.
If this reasoning is correct, then having the reset line simply pulled
up to the supply rail will result in the spec being violated and the
flash may not work for boot, which will be very bad, worse than sleep
modes not working.

But it still holds true based on the Icc3 vs. Icc4 current draw specs
that it would be better to NOT put the flash into reset during any of
our sleep modes.  What we really need is a circuit that will cause the
reset line to be pulled low during system boot (Calypso reset to be
more precise), and then leave it high afterward, no matter what the
Calypso subsequently does after it has booted.

For a long time I had a difficult time figuring out how to make the
above happen.  The relevant reset input to the Calypso is the ON_nOFF
output from the Iota ABB: during the switched-off state this signal is
held low, and the Calypso is held in reset.  During the switch-on
sequence, the ABB turns on all of its regulators, inserts a certain
delay timed by the 32.768 kHz oscillator (RTC power domain), then
drives its ON_nOFF output high to take the Calypso out of reset and
cause it to boot.  See Figure 4-8 on page 43 of TWL3025_SWRS021.pdf.

This ON_nOFF signal running from the Iota ABB to the Calypso DBB is
ideal to serve as the flash reset signal for our flash+RAM chip except
for one snafu: because it belongs in the RTC power domain, this signal
has 1.5 V logic levels, unlike all other I/O in our system (including
flash I/O pins) which runs at 2.8 V logic levels.  Connecting the 1.5V
ON_nOFF signal directly to the flash chip's reset input won't work:
it won't meet the 2.8 V flash chip's Vih spec.

But I just found what I think should be a perfect solution: we should
be able to use a dual-supply translating non-inverting buffer to
produce a 2.8 V logic version of the 1.5V ON_nOFF Calypso reset signal.
I found this translating buffer IC which should do the job:

https://www.nexperia.com/products/logic/asynchronous-interface-logic/voltage-translators-level-shifters/series/74AXP1T34.html
https://assets.nexperia.com/documents/data-sheet/74AXP1T34.pdf

If anyone else has other suggestions, feel free to bring them up - but
this 74AXP1T34 should do the trick perfectly, I think.  I would connect
its Vcci supply input to VDD_CORE, Vcco to V-FLASH, logic input A to
ON_nOFF and logic output Y to the flash reset pin.

If we all agree to this plan, the following will need to be done:

1) We will need to choose the specific package version of 74AXP1T34 -
they offer several very small package versions, which I like.

2) I will change the "schematic" source for fcdev3b-v2 in the
freecalypso-schem repository to reflect the design change and produce
the new netlist.

3) Someone will need to make the change to Altium PCB layout.  Hiring
John in Colorado once again to do this change would certainly be very
doable, but will probably be expensive - it could easily turn into
some 2-3 kUSD.  But the people I have spoken to this morning say that
they may be able to do the Altium PCB change, so we'll see...

Finally, there is one other possible approach which has been
implemented by Foxconn on the Pirelli DP-L10.  Just like our
predecessors at FIC/Openmoko, Foxconn must have started from TI's
reference design which told them to drive the flash reset line from
Calypso's FDP output, and they must have run into issues similar to
the ones we are having on our current FCDEV3B boards.  In the finished
Pirelli DP-L10 phone product there is an 0402 resistor footprint on
the PCB that allows this FDP to reset connection, but this resistor is
not populated.  Instead they have connected the flash reset line to
Calypso's TCXOEN output by way of another resistor (presumably a 0R
jumper), plus a pull-up resistor to a supply rail - although the latter
has no effect because Calypso's TCXOEN output always actively drives
either high or low.

Abusing TCXOEN as the flash reset control happens to work because this
Calypso output is held low during the boot-time reset process (when
ON_nOFF is low), then it is driven high to enable the 26 MHz VCXO, and
then there is a delay (timed via the 32.768 kHz RTC oscillator) to let
this VCXO stabilize before the ARM core boots, i.e., before the first
flash access.  Unlike FDP, TCXOEN does not go low during small sleep
or big sleep, but it does go low during deep sleep to stop the VCXO.
However, the timing of entry into and exit from deep sleep is such
that the flash chip's reset timing requirements are easily satisfied.

However, I consider Pirelli's TCXOEN solution to be suboptimal compared
to my proposal of using the ON_nOFF signal and feeding it through a
74AXP1T34 buffer.  The reason I say so is because of the rather high
Icc4 current spec given in the S29PL-N.pdf datasheet.  When the flash
chip is held down in reset (Icc4 spec applies), the current draw is
300-500 uA, whereas if it is idle (no chip select asserted) with the
reset input high (Icc3 spec), the current draw is only 20-40 uA.

A current draw of 300-500 uA may not seem like much at all, but when
the system enters deep sleep, the regulators in the ABB also switch
into sleep mode, and in this mode each regulator is limited to 1 mA
maximum.  I don't like the idea of having the flash chip needlessly
waste half of the sleep mode VRMEM regulator's budget because we are
too lazy or too cheap to go the ON_nOFF + 74AXP1T34 route.  The whole
point of the FCDEV3B is to serve as our reference design, a reference
to be copied by other FC hardware designs in the future that may have
additional hardware requiring some of that sleep mode current budget,
so I would rather do it right.

I am going to have some further off-list discussions with the people
who may be willing to help make FCDEV3B V2 a reality, but I wanted to
share the above technical info with the full community.

Hasta la Victoria, Siempre,
Mychaela aka The Mother