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
