FCDEV3B bring-up status

Serg l serg at tvman.us
Sun Apr 16 23:37:24 UTC 2017


Just a quick report that I received the board and was able to load a fresh
build of magnetite from the repo into xram.
The next step would be to perform calibration.

I see that in order to run high baud rate of the serial interface a driver
patch is needed. I have my dev environment set up on Ubuntu 16 LTS, however
it would be nice to establish some sort of a common baseline.
Build host Linux distro and version
No automatic updates, toolchain should provide reliable and predictable
environment. List of software packages installed along with their versions.
This will make troubleshooting much easier.

Should we consider hosting of the GCC based build environment in the repo,
just like Wine stuff? KVM or virtual box images? Or maybe builtroot with
selfhosted sources, so it can be rebuilt in a canonical way from scratch if
needed.


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