FCDEV3B bring-up status

Serg l serg at tvman.us
Wed Apr 5 13:25:47 UTC 2017


Excellent news!

I'm anxious to bring it into our RF lab.

I expect to have some time available to look into L1 in upcoming weeks.

-Serg

On Wed, Apr 5, 2017 at 3:22 AM, Mychaela Falconia <
mychaela.falconia at gmail.com> wrote:

> 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
> _______________________________________________
> Community mailing list
> Community at freecalypso.org
> https://www.freecalypso.org/mailman/listinfo/community
>


More information about the Community mailing list