FCDEV3B bring-up status

[Mychaela Falconia]

Hello FreeCalypso community,

Today I have received the 8 assembled FCDEV3B boards from Technotronix,
and I have powered up one of them.  Here are the parts that work:

* The power on/off control in the Iota ABB works: pressing the PWON
  button causes the green LED to turn on and powers up the Calypso,
  pressing the RESET button causes the LED to turn off while the button
  is depressed and turn back on when it is released, power-cycling and
  hard-resetting the Calypso as expected.

* The Calypso chip is alive and the versions of its boot and DSP ROMs
  are as expected: I can run fc-loadtool -h fcfam on either /dev/ttyUSB0
  or /dev/ttyUSB1 (two Calypso UARTs behind my FT2232D adapter), induce
  the boot sequence via either the PWON or the RESET button, and our
  loadagent happily loads and runs.  The boot ROM version is 0300 like
  on all other Calypso devices we work with, and the DSP ROM version is
  3606 as it should be, confirmed when booting FC Magnetite firmware -
  see below.

* The Spansion flash+pSRAM chip copied from the Pirelli DP-L10 also
  works: once in fc-loadtool, I can operate on both of its flash banks,
  and I successfully loaded our FC Magnetite fw image built for the
  fcdev3b target into the flash.

* The firmware boots and is alive on both UARTs: standard AT command
  interface on /dev/ttyUSB0, RVTMUX on /dev/ttyUSB1.  There is, however,
  some strange issue with booting from flash (as opposed to fc-xram)
  which I need to investigate further before I can make any intelligent
  observations: it appears that when booting from flash, the fw first
  crashes on boot with an undefined instruction exception, reboots, and
  then boots successfully on the second or some subsequent cycle.  So
  far this issue has not been a stopper: usually it does boot after all,
  and the one time I couldn't get it to boot from flash, I booted a
  RAM-based version of the same fw via fc-xram.  But of course the issue
  needs to be investigated and solved, and I will probably use JTAG for
  this investigation.

* With a workaround, I was able to bring up the SIM interface, and it
  works: I was able to retrieve the number of my test SIM and see its
  phonebook and SMS storage.

Now here are the problems encountered so far:

* There is a defect in the PCB layout which my Iranian contacts did
  for us on a barter basis when we didn't have the money to hire a PCB
  layout professional on commercial terms: the headers for MCSI, UARTs
  and JTAG (from left to right in this order) are too close together,
  i.e., there is too little gap between adjacent headers.  As a result,
  when a ribbon cable is connected to the dual UART header in the middle
  (the most critical of the three), this cable gets in the way of
  connecting to MCSI or JTAG on either side of it.

  So far I have connected only the UARTs, but when I need to connect
  JTAG as well (which will be soon as I'll need it in order to
  investigate the mysterious boot issue), I will have to forego the
  convenience of ribbon cables and use individual single wire
  connections as a workaround.  Ditto when we reach the point of
  playing with MCSI.  A pita, but it will allow us to proceed forward
  with the bring-up.

* The mysterious boot issue described above.

* Without additional workarounds, issuing an AT+CFUN=1 command to the
  fw to bring up the radio and SIM interfaces causes an immediate
  reboot without any indication as to what the problem may be,
  suggesting a problem with the power supplies on the board.  However,
  if I issue an AT%SLEEP=0 command (disable all sleep modes) before the
  AT+CFUN=1, then the latter succeeds and the SIM becomes accessible
  as described above.

  I need to investigate further what happens in the processing of the
  AT+CFUN=1 command and where the deep sleep or possibly other sleep
  modes come into play.

Finally, the big one: once I was able to get the SIM up with AT+CFUN=1
after disabling sleep with AT%SLEEP=0, my next try was to bring up the
radio with AT+COPS=0.  Alas, no joy there: from my cursory reading of
the log (see below), the modem is unable to acquire the frequency burst
on any of the channels it detected as cell candidates in the power
measurement.  Now this problem could be as simple as the lack of VCXO
calibration, or it could be some serious defect in the RF tract.

Here are the logs:

https://www.freecalypso.org/members/falcon/fcdev3b/fcdev3b-1st-boot.log
https://www.freecalypso.org/members/falcon/fcdev3b/radio-bringup-attempt.log

The first log shows the boot cycle mystery (see lines 156 through 159);
the second log shows the reboots caused by issuing AT+CFUN=1 and then
the successful SIM bring-up and the not-so-successful radio bring-up
with the AT%SLEEP=0, AT+CFUN=1, AT+COPS=0 sequence.

Now the GSM radio tract is what makes this board interesting: all of
the non-radio functions can be performed just as well or usually much
better by all kinds of other readily available and well-documented
hardware out there, thus getting this radio tract working should be
our main focus.

The proper next step in debugging the radio tract is to connect our
board to an R&S CMU200 radio tester and try some elementary Rx and Tx
operations via L1 Test Mode commands, similarly to what happens in a
calibration procedure.  I do have a CMU200 at home (bought on ebay
within the past month, and just setup last Saturday), but I am at my
day job until Friday evening, so it will have to wait till next weekend
before I can play with it.  I also need RF cables to go from the N-type
connector on the CMU200 to the SMA on the FCDEV3B and to the MS-147 RF
test port on the GTA02 (a known good reference for comparison), but
these cables are already on order and are expected to arrive by Friday.

Hasta la Victoria, Siempre,
Mychaela aka The Mother