FCDEV3B update

[Mychaela Falconia]

Hello FC community,

It's time for another update on the FCDEV3B project and some related
happenings.  As I posted here earlier, the order for FCDEV3B PCB
fabrication was placed on 20170109 with pcbcart, a Chinese PCB
manufacturer.  Shortly after I submitted the order and sent the Paypal
payment for $2480.04 USD, they started coming back to me with various
questions about the order.  Every question they asked me required me
to do more research and learning (i.e., go deeper and deeper down the
rabbit hole), but eventually I was able to resolve most of them.

There is, however, one unresolved question which we may only be able
to answer experimentally, i.e., by trial and error.  Because our
Calypso+RF modem core is copied directly from Openmoko GTA02 at the
physical layout level, our board needs to have the same essential
structure as the GTA02 motherboard: at the minimum, the same number of
copper layers (8) and the same structure for blind and buried vias.
However, my original intent was to take our copying of the GTA02 one
step further and replicate not only the layer count and via drill
structure, but the complete physical layer stackup: the exact thickness
of every copper layer and the exact material type and thickness of
every dielectric layer in between.

We do have FIC/Openmoko's original fabrication notes for GTA02-MB-A6
which indicate the complete physical layer stackup they used:

ftp://ftp.freecalypso.org/pub/GSM/GTA02/GTA02-MB-A6_fab_notes.pdf

The document is mostly in Chinese (despite all those Germans, Openmoko
hardware design was still done in Taiwan with manufacturing in
mainland China, it seems), but the layer stackup description is
readable nonetheless.  This stackup description includes not only the
thickness of each copper and dielectric layer (needed for microstrip
and stripline impedance calculations), but also the exact material
type (as in fiberglass fabric weave type and resin content percentage)
for each "prepreg" dielectric layer.

I originally sought to replicate this exact physical stackup verbatim
for our FCDEV3B, and I had copied the stackup description from the
Chinese PDF into my own fab notes for the FCDEV3B.  But when the
people at pcbcart took a sufficiently thorough look at our design
files (including this stackup request) after receiving the order and
the payment, they came back to me and said that they need to change
the stackup.  I asked them why they couldn't replicate the old stackup
from the GTA02 verbatim, and they said they don't have the PP 1078
material, which Om's fab notes specify for the L1-L2, L2-L3, L6-L7 and
L7-L8 dielectrics.  I asked them if they could procure this type of
prepreg specifically for our board order, and they made me wait about
a week, saying they were looking into it, but then they came back and
said they couldn't get it.  They also gave me the impression that this
type of prepreg is very uncommon, at least nowadays - I don't know
what the situation was in the days of Openmoko.

The big question here to which we have no answer is whether the layer
stackup listing in Om's old fab notes is a description or a
prescription: were they using PP 1078 because 10 y ago the situation
was different, this type of PP was common and this stackup was used
regularly by their fab at the time, or do they specifically call for
PP 1078 no matter how uncommon or expensive it may be because it is
needed for some technical reason?  Unfortunately, we have no answer to
this question, hence I'm afraid that we'll have to go with trial and
error.

Pcbcart proposed an alternative physical stackup in which the copper
layers stay exactly the same (8 total, 1 oz copper on each), but the
dielectic thicknesses are a little different:

https://www.freecalypso.org/members/falcon/fcdev3b/pcbcart/stackup-20170119.png

It's a bit counter-intuitive, but the numbers on the left in mils are
the thickness values for the dielectrics alone, whereas the numbers on
the right in mm give the thickness of the dielectric plus the copper
foil where the description in the middle column includes one of the
latter.  Also where it says 18 um for the top and bottom copper layers
(corresponding to half-oz copper), that's the copper before the
plating; they said the finished copper thickness after the plating
will correspond to 1 oz as required.  If we accept their stackup
proposal, they will also adjust the trace widths for controlled
impedance as follows:

* 50 ohm microstrips on L8 will need to be widened from 11 mil to
  12.8 mil;

* 50 ohm striplines on L5 will need to be shrunk from 6.95 mil to
  5.15 mil.

Based on my very limited knowledge as an outsider (i.e., as someone
who doesn't know why the cellular industry 10 y ago did things the way
they did and not some other way), I don't see anything wrong with the
stackup proposed by pcbcart, i.e., as long as they maintain the
impedance of our RF traces within 10% of the expected 50 ohm (Om's
original fab notes also say 10% tolerance for the impedance), I don't
foresee any problems with the functioning of the circuit.  But then
again, I am an outsider who constantly scratches her head in
bewilderment at why things were done the way they were, and not a true
expert by any means.

In any case, given that pcbcart folks say they can't reproduce the
original GTA02 layer stackup verbatim, including the use of PP 1078,
we practically have two choices at this point:

1. We can accept pcbcart's proposed stackup change and give them the
   go-ahead to proceed with fabrication.

2. We can tell pcbcart to cancel the order, demand a Paypal refund,
   and go back to square one, looking for other PCB fabs who may be
   able to use PP 1078 and reproduce Om's original stackup exactly,
   likely at a much higher cost, and we don't even know if anyone does
   PP 1078 any more.

Given our circumstances, my own leaning is toward option 1.  Given
that we really don't know if the use of PP 1078 is necessary or if
using an alternate stackup like the one proposed by pcbcart is just
fine, it does not make sense to me to throw ourselves back to square
one and probably spend a lot more money because of this uncertainty.
Yes, there is the risk with option 1 that after we have spent the
money getting our boards built, we may discover that the resulting
boards have degraded RF performance (poorer Rx sensitivity, higher BER
or needing more source power to produce the same Tx power levels at
the antenna) compared to Openmoko's original because of the stackup
change.  But then we have plenty of other risk factors (we won't know
for certain if our Calypso and other chips are good until we spend the
money and get our boards built, for example), and like it or not, we
have to take these risks in order to advance our project forward.

Right now I have an outstanding email inquiry to the anonymous person
whose very generous donation of 3000 EUR has paid for the current
on-hold order with pcbcart - I need that person's approval (or a
timeout) before I can proceed with option 1 per my own leanings.  If I
get this person's approval, or if I hear nothing back by next Friday,
I will give my go-ahead to pcbcart, let them build our boards with
their stackup and hope for the best.

The "hope for the best" part requires an explanation of its own.  The
arguably most essential part of a Calypso GSM device, the part that
actually makes it a GSM device as opposed to any run-of-the-mill
general-purpose microprocessor board, is the radio tract, but it is
not the first part to be tested during bring-up.  When I get the first
few boards populated with parts, the first bring-up milestone we'll
need to achieve (after the power-up sequence) will be talking to the
Calypso boot ROM via the UARTs, loading some code into the Calypso
on-chip internal RAM and running that code, e.g., by running
fc-loadtool and having it successfully load and run loadagent on the
target.  Once we have reached this milestone, the next step will be to
get the external (board level) flash+pSRAM chip working, i.e., have
working XRAM and the ability to load code into flash.  Only then we'll
be able to run our first firmware image, and even at this point the
radio tract could be missing altogether!  Once we can get a firmware
image running (after having got the Calypso boot ROM, the UARTs and
the flash+XRAM chip working), we'll be able to check out the SIM
interface, and only then try bringing up the radio...

OK, so assuming that all of listed prerequisites pass and we reach the
point of being ready to start exercising the GSM radio part of our
board, how do we actually do the latter?  If the SIM interface works,
I'll try the quick and easy way: insert a SIM, issue an AT+CFUN=1
command followed by AT+COPS=0, and see if the modem is able to pick up
and register to the live GSM network in my neck of the woods.  Yes, I
know full well that firing up a completely untested experimental MS
against a live network is against all rules, but I am a naughty girl
used to breaking rules, and it is by far the quickest and easiest test.
But if this quick&easy test fails, or if there is a problem with the
SIM interface such that we would like to bypass the latter and try
bringing up the radio without the SIM, we'll need to do the slow and
proper way: L1/RF test modes and calibration.

Going through the complete RF test and calibration procedure will be
the only way to objectively evaluate the RF performance of our boards
and to compare it against that of the Openmoko-made GTA02, and to give
our boards the proper fighting chance of being able to operate on
commercial GSM networks.  Even if get lucky and succeed in connecting
to a live network in the uncalibrated state, we are still going to
need to do the calibration to ensure fully reliable operation, and if
we don't get so lucky, we'll need to reserve judgment until we have
tried calibration.  The results of the RF calibration tests will also
give us an objective empirical answer as to whether or not it was
acceptable to change the board layer stackup details, and several
other currently unanswerable questions of similar nature.

Given the importance of the RF test and calibration procedures, I've
been making some preparations for venturing into that land ahead of
the boards.  There are two parts to these RF test and calibration
procedures:

* External RF test equipment to be connected to the device under test
  in place of the GSM antenna.  TI used Rohde & Schwarz CMU200;
  looking on ebay, I see several of them up for sale on any given day,
  with prices ranging from affordable to really expensive.  Of course
  I don't know what the catch may be with the lower-priced units - I
  still have a lot of learning ahead of me.

* Special L1/RF test processes to be executed on the Calypso device
  itself.  We need to get this part fully under our control before it
  will make any sense to acquire a CMU200 or other external test
  equipment, hence I am currently focusing on this part.

As the first preparatory step toward RF calibration and test
procedures, I have deblobbed the part of L1 responsible for the test
modes.  TI's official TCS211 firmware for the Calypso includes a
special component for executing RF test operations; this component is
implemented inside L1 and remains a part of the fw images shipped with
products, but it lies dormant until and unless it receives special
command packets over the debug trace UART port aka RVTMUX.
Manufacturers of TI-based GSM devices who followed TI's canonical way
of doing things without major rearchitecting - Openmoko being the best
example - programmed their devices at the factory with a TCS211-based
fw image, then sent those special commands to the device running the
fw to perform the per-unit RF calibration, and then kept the same fw
for the shipping product, i.e., there is no special code that needs to
be flashed or executed out of RAM just for production tests and
calibration, and the code intended to only ever run on the factory
production line remains in the shipped products.

Because the fw component in question is implemented as part of L1, we
have received the canonical Calypso/TCS211 version of this component
in the form of binary blobs rather than source, just like the rest of
L1.  The core parts of L1 (everything except audio functions, test
modes and GPRS-specific code) have been successfully deblobbed back in
the first half of 2016, i.e., I successfully reconstructed C code that
compiles into an equivalent of the binary blobs we got with the
official delivery, but l1audio and l1tm were left for later.  Well, I
am proud to announce that l1tm has now been deblobbed too; you can
find this work in the tcs211-l1-reconst Hg tree.  At the present time
I don't seek to make any changes to this code, and I would like our RF
test and calibration procedures to work against the unmodified blob-
laden TCS211 fw build, but having reconstructed the source to the l1tm
code allows us to study and understand it.

But the l1tm code inside the firmware is only one part; the other part
of the magic lies in the host tools that send those special command
packets that awaken the l1tm beast.  Unfortunately TI made their host
tools only for Windows, AFAIK most devices manufacturers only got them
as Windows EXE and DLL binaries sans source, and even in the case of
those Windows binaries, I haven't been able to locate all of them.  We
have the Windows binaries for PCO (a G23M stack debug tool) and CSST
(a LoCosto-ism, I don't know if it can work with Calypso at all), but
not FLUID or any of their PCTM or TMSH tools.  FLUID was their low-
level flashing tool which is now fully supplanted by our fc-loadtool,
but we still need to write our own replacement for TI's PCTM or TMSH.

It appears that TI's original Winblows tool for sending Test Mode
commands to their GSM firmwares and catching the responses was called
PCTM, and then at some point it got renamed or transformed into
something they called TMSH for Test Mode Shell - perhaps this change
happened at the same time when ETM joined the original non-enhanced TM
on the firmware side, or maybe the two happened at different times.
As I already said, I haven't found any Windows binaries (let alone
sources) for either PCTM or TMSH, but we have a couple of TI documents
which explain how to perform RF test and calibration procedures using
PCTM or TMSH commands, thus giving examples of their syntax, and I
also found a seemingly-complete listing of TMSH commands on this web
page:

http://elinux.org/Peek#Tools

Looking at that list of commands, one can clearly see that some of
them are FFS (flash file system) operations which we have already
implemented in our own different way in our fc-fsio utility, a few are
generic memory and register peeks and pokes that can be implemented
either through older TM3 command packets to the fw or newer ETM ones,
and then there are the L1/RF test mode commands which we'll need for
our test and calibration procedures.

I had heard of at least the name TMSH quite early in the FreeCalypso
project, thus as far back as 2013-11 when I started writing our first
host utility for sending ETM command packets to running fw, I named it
fc-tmsh.  This fc-tmsh program still exists in the present FreeCalypso
host tools suite, and it serves approximately the same purpose as TI's
TMSH (to the extent to which I can make inferences about the latter
without actually having a copy): sending TM and ETM commands to
running GSM device firmwares and receiving and displaying fw responses
to these commands.  Our fc-tmsh is strictly a low-level tool: each
command typed by the operator results in a corresponding TM/ETM packet
being sent to the target.  TI's TMSH appears to include both elementary
operations of this sort as well as some higher-level commands for FFS
where a single user command corresponds to quite a few complex ETM
packet exchanges with the target; in our case we have moved these
complex FFS operations from fc-tmsh into fc-fsio, a separate utility
with a very different internal architecture that is more suitable for
performing complex sequences of elementary operations.

Right now our fc-tmsh bears no resemblance at all to TI's TMSH: no FFS
commands in fc-tmsh (and the ones that are implemented in fc-fsio have
entirely different names, syntax and command repertoire), no L1/RF
test mode commands yet, and for the few ETM operations which are
supported by both TI's TMSH and our fc-tmsh, the syntax is once again
different.  This incompatibility is what usually happens when you have
to do a from-scratch reimplementation without being able to even look
at the original...

But I am hoping to mend this rift between TI's PCTM/TMSH and our fc-tmsh
at least a little bit in the case of the L1/RF test mode commands.
Even though we don't have a copy of TI's PCTM or TMSH, we now have the
reconstructed source for the l1tm target-side code that receives and
acts upon the commands sent by these Windows tools, and we have TI
documents with examples of how PCTM and TMSH commands were typed.  The
command packet types (called CIDs) which can be sent to l1tm via the
TM3 protocol are defined in l1tm_msgty.h on the GSM fw side (look in
the tcs211-l1-reconst repository), and the names of user commands
implemented by TI's TMSH are listed on the web page above.  Comparing
the two, there is a very obvious one-to-one correspondence:

tms command sends a TM_MODE_SET packet
rfe command sends an RF_ENABLE packet
rfpw command sends an RF_PARAM_WRITE packet

and so forth.  Furthermore, the examples of these commands in TI's RF
calibration tutorial documents show very clearly that the arguments to
these commands (all numbers) go directly into those command packets in
the most straightforward manner, without any intelligence on the part
of the Windows tool.  Thus if I implement these commands in the most
straightforward manner in our fc-tmsh, we'll provide essentially the
same operator experience as TI's tools did, and the syntax given in
TI's RF calibration tutorials should work with our Free Software tools.

The only commands which I plan on implementing differently from TI's
tools are rftw for sending RF_TABLE_WRITE packets and ttw for sending
TX_TEMPLATE_WRITE.  The ttw packet carries a payload of 32 bytes
giving the Tx power ramp-up and ramp-down profiles; the rftw packet
carries different payload types and formats depending on the opcode
(the first numeric argument after the rftw command keyword), but these
tables range from 24 to 128 bytes.  Adjusting for 16-bit and 32-bit
fields, the count of decimal numbers going into a single table to be
sent with a single rftw command ranges from 8 to 96; I dunno about
others, but I do not particularly feel like entering a table of 96
numbers all on one line.  Hence I plan on making fc-tmsh versions of
these commands read the to-be-sent table content from sensibly
formatted text files.

So far I have implemented tms, rfe, scw, scr, sr, rfpw and rfpr
commands in fc-tmsh; rftw, rftr, rxpw, rxpr, txpw, txpr, ttw, ttr,
mpw, mpr and me remain to be implemented.  I was working on this code
last weekend, but then paused to decide what to do about the big table
sending commands.  I will need to finish this implementation (either
before or after we get our FCDEV3B boards built) before we can start
really playing with L1/RF test modes.

Hasta la Victoria, Siempre!