I was also curious if we load OsmocomBB into it and see what will it say...
On Wed, Apr 5, 2017 at 3:22 AM, Mychaela Falconia < mychaela.falco...@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@freecalypso.org > https://www.freecalypso.org/mailman/listinfo/community > _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community
