Re: FCDEV3B bring-up status

[Serg l]

Excellent! I could see all that infrastructure, but could not figure out
how the trace flags are set up. TRACECLASS does real magic. I flashed
Citrine and trying to capture some traces of states and primitives sent
between entities. I was able to observe few successful runs when board was
able to register. When it does register, it works just fine, otherwise it
is getting stuck for unknown reason. I will collect more details and report
back if anybody is still interested in working with Citrine which actually
works without AT%SLEEP=0 :)

BTW I checked wineconsole and it looks like not the right tool as it does
even more work than regular wine for console applications. I also noticed
that wineserver is restarted for every command, maybe if we can make use of
persistent wineserver, some performance improvement could be observed.
Another option is to split the build into multiple parallel jobs because
CPU load is almost zero during the compilation. This should speed up the
process, IMHO

On Sun, May 7, 2017 at 12:23 PM, Mychaela Falconia <
mychaela.falco...@gmail.com> wrote:

> Hi Serg,
>
> > Tried Magnetite hybrid and it worked without any problems with any SIM
> > I have.
>
> OK, so you have a SIM which works with Magnetite hybrid but not with
> Citrine?  Is there anything special about that SIM, or is it just
> another regular SIM from Operator 310260?
>
> If Magnetite hybrid works but Citrine does not, the next logical step
> in narrowing down the difference should be to try building Magnetite
> in a hybrid config with FAX_AND_DATA and GPRS disabled (to match
> Citrine), but such config has not been created yet.
>
> > Compilation time is really long.
>
> Yes, the long compilation time of Magnetite hybrid is really bothersome.
>
> > I didn't really profile
> > anything, but I noticed that wine is trying to setup graphical
> > environment to run every command.
>
> Yeah, I figured it was doing that.
>
> > Have you considered wineconsole instead?
>
> I've been ignorant of its existence.  You can try changing the nowhine
> wrapper to invoke wineconsole instead of wine, and see if it makes a
> difference.
>
> > not working:
> > GPF trace id=A7 ts=00019420 PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
> > sat_enabled = 0, modus = 255"
> >
> > working:
> > GPF trace id=A7 ts=7F1B PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
> > sat_enabled = 1, modus = 255"
>
> You know that SAT is SIM Application Toolkit, right?
>
> > I like Citrine flavor :) because it is built completely with GCC and
> > it is really fast to recompile even from scratch.
>
> I naturally also desire to have fw that builds with gcc and thus
> avoids all that grossly inefficient Wine nastiness.  However, over the
> years that I've been working on FreeCalypso, the 3 y that went by
> since I did the fw approach that later became Citrine (our first
> attempt at FreeCalypso GSM fw), my vision has evolved and changed, and
> I no longer consider my original approach (that led to current Citrine)
> of reintegrating the fw suite piece by piece from the bottom up to be
> such a good idea.
>
> Instead my current thinking is to approach the end goal of blob-free
> gcc-built fw with full functionality of TCS211 incrementally, changing
> one variable at the time, starting wtth TCS211.  The first change was
> to deblob L1 one C module at a time, keeping everything else the same,
> the next step (Magnetite hybrid) is to replace the blob version of
> G23M with the source version, still keeping everything else the same
> (including the compiler toolchain and the not-yet-deblobbed pieces),
> and so forth.  Once all of Magnetite has been fully deblobbed one
> piece at a time, then try migrating it to gcc with just a compiler
> change, i.e., without moving header files around and changing the way
> in which the configuration is set and all other big rearchitecturing
> changes of Citrine which go beyond the compiler toolchain.
>
> But of course the above is a very long-term plan.
>
> > I was trying to figure out how do the trace flags work in Citrine
>
> They work the same way in Citrine as in the original TCS211; read this
> TI document:
>
> https://www.freecalypso.org/LoCosto-docs/SW%20doc/frame_users_guide.pdf
>
> and pay particular attention to the description of traces and the
> TRACECLASS system primitive.  With our tools the way to send system
> primitives to a running fw is the sp command in fc-shell.
>
> [in the follow-up post]
> > I have enabled function names tracing by directly applying trace TC_FUNC
> > flag in InitializeTrace function. It seems to be not the right way of
> doing
> > this, but it made the rick.
>
> No, it is not the right way, see the TRACECLASS system primitive for
> the right way.
>
> > Please see a side-by-side trace of two equal runs, one where I got
> > successful registration and the other when I was observing the issue.
>
> All noise and no signal.  Enabling TC_FUNC traces across all entities
> in the entire G23M stack is not a useful 

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Hi Serg,

> Tried Magnetite hybrid and it worked without any problems with any SIM
> I have.

OK, so you have a SIM which works with Magnetite hybrid but not with
Citrine?  Is there anything special about that SIM, or is it just
another regular SIM from Operator 310260?

If Magnetite hybrid works but Citrine does not, the next logical step
in narrowing down the difference should be to try building Magnetite
in a hybrid config with FAX_AND_DATA and GPRS disabled (to match
Citrine), but such config has not been created yet.

> Compilation time is really long.

Yes, the long compilation time of Magnetite hybrid is really bothersome.

> I didn't really profile
> anything, but I noticed that wine is trying to setup graphical
> environment to run every command.

Yeah, I figured it was doing that.

> Have you considered wineconsole instead?

I've been ignorant of its existence.  You can try changing the nowhine
wrapper to invoke wineconsole instead of wine, and see if it makes a
difference.

> not working:
> GPF trace id=A7 ts=00019420 PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
> sat_enabled = 0, modus = 255"
>
> working:
> GPF trace id=A7 ts=7F1B PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
> sat_enabled = 1, modus = 255"

You know that SAT is SIM Application Toolkit, right?

> I like Citrine flavor :) because it is built completely with GCC and
> it is really fast to recompile even from scratch.

I naturally also desire to have fw that builds with gcc and thus
avoids all that grossly inefficient Wine nastiness.  However, over the
years that I've been working on FreeCalypso, the 3 y that went by
since I did the fw approach that later became Citrine (our first
attempt at FreeCalypso GSM fw), my vision has evolved and changed, and
I no longer consider my original approach (that led to current Citrine)
of reintegrating the fw suite piece by piece from the bottom up to be
such a good idea.

Instead my current thinking is to approach the end goal of blob-free
gcc-built fw with full functionality of TCS211 incrementally, changing
one variable at the time, starting wtth TCS211.  The first change was
to deblob L1 one C module at a time, keeping everything else the same,
the next step (Magnetite hybrid) is to replace the blob version of
G23M with the source version, still keeping everything else the same
(including the compiler toolchain and the not-yet-deblobbed pieces),
and so forth.  Once all of Magnetite has been fully deblobbed one
piece at a time, then try migrating it to gcc with just a compiler
change, i.e., without moving header files around and changing the way
in which the configuration is set and all other big rearchitecturing
changes of Citrine which go beyond the compiler toolchain.

But of course the above is a very long-term plan.

> I was trying to figure out how do the trace flags work in Citrine

They work the same way in Citrine as in the original TCS211; read this
TI document:

https://www.freecalypso.org/LoCosto-docs/SW%20doc/frame_users_guide.pdf

and pay particular attention to the description of traces and the
TRACECLASS system primitive.  With our tools the way to send system
primitives to a running fw is the sp command in fc-shell.

[in the follow-up post]
> I have enabled function names tracing by directly applying trace TC_FUNC
> flag in InitializeTrace function. It seems to be not the right way of doing
> this, but it made the rick.

No, it is not the right way, see the TRACECLASS system primitive for
the right way.

> Please see a side-by-side trace of two equal runs, one where I got
> successful registration and the other when I was observing the issue.

All noise and no signal.  Enabling TC_FUNC traces across all entities
in the entire G23M stack is not a useful way to debug such issues,
instead you should begin by examining the flow of primitives between
entities and see where the first diff occurs, and then hopefully know
which protocol stack entity you should be looking at in more detail,
with more traces enabled.

TC_PRIM is the trace class you should start with, and I would not
recommend enabling it for all entities at once, as that would again
produce too much noise.  Instead begin with the MMI entity, then look
at the entities it communicates with, and go down from there.

I assume you've read my doc/Firmware_Architecture write-up in the
Citrine source tree - I have just updated the stale links to docs at
the end to their new FTP and web locations.

M~
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

I have enabled function names tracing by directly applying trace TC_FUNC
flag in InitializeTrace function. It seems to be not the right way of doing
this, but it made the rick.
Please see a side-by-side trace of two equal runs, one where I got
successful registration and the other when I was observing the issue.

​
 citrine.htm

​

On Sat, May 6, 2017 at 8:40 PM, Serg l  wrote:

> Mychaela,
> Tried Magnetite hybrid and it worked without any problems with any SIM
> I have. Compilation time is really long. I didn't really profile
> anything, but I noticed that wine is trying to setup graphical
> environment to run every command. Have you considered wineconsole
> instead?
>
> I reviewed Citrine log from S/N1 and this is the difference
>
> not working:
> GPF trace id=A7 ts=00019420 PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
> sat_enabled = 0, modus = 255"
>
>
> working:
> GPF trace id=A7 ts=7F1B PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
> sat_enabled = 1, modus = 255"
>
> I like Citrine flavor :) because it is built completely with GCC and
> it is really fast to recompile even from scratch.
>
> I was trying to figure out how do the trace flags work in Citrine, I'd
> like to find out how we end up in the function cb_mmi_sat_cbch_req()
> after enabling CFUN=1
>
> General tracing seems to be enabled, but I need more details not only
> errors. If you have any suggestions, I would really appreciate this.
>
> -Serg
>
> On 5/6/17, Mychaela Falconia  wrote:
> > Hi Serg,
> >
> >> It worked once with different SIM card, but it is definitely not a
> >> hardware
> >> issue because Magnetite build works every time with the same SIM card.
> >> Maybe L1/DSP is configured a bit differently and if my calibration
> values
> >> are a bit off, Citrine may not be able to detect carriers.
> >
> > I don't see how the quality of calibration could be the cause of the
> > problem you are having with Citrine, as your log shows that the fw
> > does not even attempt to connect to a cell, i.e., the upper layers of
> > the G23M protocol stack are not commanding L1 to make a network sync
> > attempt.  And because L1 is not being commanded to do the operation in
> > question, I don't see how it could be an L1 or DSP problem either -
> > instead it must be some glitch higher up in the protocol stack code.
> >
> > The G23M PS used in Citrine is not too polished, i.e., it may still
> > have bugs that need to be shaken out, and the issue you are having
> > looks like one of them.  However, my preferred approach to debugging
> > these G23M PS problems is to debug them first in the TCS2/TCS3 hybrid
> > config of Magnetite (see doc/Modem-configs in the fc-magnetite source
> > tree), and then port to Citrine if there is commercial demand for the
> > latter.
> >
> > Thus you might want to try building Magnetite in the hybrid config
> > (different from the l1reconst config I currently use and recommend for
> > production use), and see if the SIM that's giving you trouble in
> > Citrine works in Magnetite TCS2/TCS3 hybrid or not - this experiment
> > would narrow the search for the bug.
> >
> > M~
> > ___
> > 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

Re: FCDEV3B bring-up status

[Serg l]

Mychaela,
Tried Magnetite hybrid and it worked without any problems with any SIM
I have. Compilation time is really long. I didn't really profile
anything, but I noticed that wine is trying to setup graphical
environment to run every command. Have you considered wineconsole
instead?

I reviewed Citrine log from S/N1 and this is the difference

not working:
GPF trace id=A7 ts=00019420 PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
sat_enabled = 0, modus = 255"


working:
GPF trace id=A7 ts=7F1B PL->PCO tc=07 "HM cb_mmi_sat_cbch_req(),
sat_enabled = 1, modus = 255"

I like Citrine flavor :) because it is built completely with GCC and
it is really fast to recompile even from scratch.

I was trying to figure out how do the trace flags work in Citrine, I'd
like to find out how we end up in the function cb_mmi_sat_cbch_req()
after enabling CFUN=1

General tracing seems to be enabled, but I need more details not only
errors. If you have any suggestions, I would really appreciate this.

-Serg

On 5/6/17, Mychaela Falconia  wrote:
> Hi Serg,
>
>> It worked once with different SIM card, but it is definitely not a
>> hardware
>> issue because Magnetite build works every time with the same SIM card.
>> Maybe L1/DSP is configured a bit differently and if my calibration values
>> are a bit off, Citrine may not be able to detect carriers.
>
> I don't see how the quality of calibration could be the cause of the
> problem you are having with Citrine, as your log shows that the fw
> does not even attempt to connect to a cell, i.e., the upper layers of
> the G23M protocol stack are not commanding L1 to make a network sync
> attempt.  And because L1 is not being commanded to do the operation in
> question, I don't see how it could be an L1 or DSP problem either -
> instead it must be some glitch higher up in the protocol stack code.
>
> The G23M PS used in Citrine is not too polished, i.e., it may still
> have bugs that need to be shaken out, and the issue you are having
> looks like one of them.  However, my preferred approach to debugging
> these G23M PS problems is to debug them first in the TCS2/TCS3 hybrid
> config of Magnetite (see doc/Modem-configs in the fc-magnetite source
> tree), and then port to Citrine if there is commercial demand for the
> latter.
>
> Thus you might want to try building Magnetite in the hybrid config
> (different from the l1reconst config I currently use and recommend for
> production use), and see if the SIM that's giving you trouble in
> Citrine works in Magnetite TCS2/TCS3 hybrid or not - this experiment
> would narrow the search for the bug.
>
> M~
> ___
> 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

Re: FCDEV3B bring-up status

[Serg l]

It worked once with different SIM card, but it is definitely not a hardware
issue because Magnetite build works every time with the same SIM card.
Maybe L1/DSP is configured a bit differently and if my calibration values
are a bit off, Citrine may not be able to detect carriers.

I'm not really concerned about this right now. I will keep you posted about
progress.

On Fri, May 5, 2017 at 1:17 PM, Mychaela Falconia <
mychaela.falco...@gmail.com> wrote:

> Hi Serg,
>
> > However still no joy. I have log file here for now [...]
> >  LGWaryBRksQS01Wll1V1lIb19vZVRCMC1WVWk5akZxem1r/view?usp=drive_web>
>
> The firmware behaviour seen in your log does look strange; I have never
> seen any fw behave like this.  When you issue at+cops=0, it starts as
> expected by switching between EU and US band pairs (BAND_R/BAND_C
> exchanges) and running power measurements across all channels in each
> band pair (RXL_R/RXL_I exchanges) - so far, so good.  But then the fw
> should start making FB acquisition attempts on the best candidate
> channels, whereas your log shows all activity stopping at that point,
> just the ADC traces that are seen in the no-GSM-running state.
>
> When I previously tested Citrine fw on the FCDEV3B a few days ago, I
> did not take it as far as trying network connection, so I just tried
> it now.  I booted my Citrine build from 2-3 days ago (via fc-xram) and
> issued the same AT commands I usually use to test network connection,
> and it worked just fine for me, no worse than Magnetite.
>
> I just made this tarball:
>
> https://www.freecalypso.org/members/falcon/fcdev3b/
> citrine-20170505.tar.bz2
>
> Inside you will find the ramImage I used, the build.conf it was built
> from, and the log of my successful network connection with this fw on
> FCDEV3B S/N 001.
>
> M~
> ___
> 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

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Hi Serg,

> However still no joy. I have log file here for now [...]
> 

The firmware behaviour seen in your log does look strange; I have never
seen any fw behave like this.  When you issue at+cops=0, it starts as
expected by switching between EU and US band pairs (BAND_R/BAND_C
exchanges) and running power measurements across all channels in each
band pair (RXL_R/RXL_I exchanges) - so far, so good.  But then the fw
should start making FB acquisition attempts on the best candidate
channels, whereas your log shows all activity stopping at that point,
just the ADC traces that are seen in the no-GSM-running state.

When I previously tested Citrine fw on the FCDEV3B a few days ago, I
did not take it as far as trying network connection, so I just tried
it now.  I booted my Citrine build from 2-3 days ago (via fc-xram) and
issued the same AT commands I usually use to test network connection,
and it worked just fine for me, no worse than Magnetite.

I just made this tarball:

https://www.freecalypso.org/members/falcon/fcdev3b/citrine-20170505.tar.bz2

Inside you will find the ramImage I used, the build.conf it was built
from, and the log of my successful network connection with this fw on
FCDEV3B S/N 001.

M~
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

Looks like I didn't pay attention to what is the true meaning of tmffs2
feature. Turns out it is mandatory feature which needs to be included, but
we need to choose the FFS driver version 1 vs 2 and that what tmffs1 vs
tmffs1 do.

Once added I was able to access FFS in Magnetite flashed in and Citrine
from xram load.

However still no joy. I have log file here for now and plan to flash
Citrine today, just to see if it makes any difference.

I will try to enable more traces to find out where does it die
​
 citrine.txt

​

On Thu, May 4, 2017 at 3:35 AM, Mychaela Falconia <
mychaela.falco...@gmail.com> wrote:

> Hi Serg,
>
> It looks like your Citrine build.conf is missing feature tmffs2;
> fc-fsio won't work without this feature.  Try rebuilding with this
> feature added and see if it starts working then.
>
> > Didn't have chance to test this, but seems like FLASH2_BASE_ADDR is not
> > defined anywhere, but I guess it should be 0x0180 ?
>
> It is defined in cfgmagic/target.fcdev3b, from where it propagates
> into the include/config.h generated file, which is then included by
> all C source files.  And yes, 0x0180 is the correct FLASH2_BASE_ADDR
> for the FCDEV3B and for all future FreeCalypso hw designs which will
> use the same Spansion chip with the 2nd flash chip select connected to
> Calypso nCS2 per Leonardo reference schematics.
>
> M~
> ___
> 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

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Hi Serg,

It looks like your Citrine build.conf is missing feature tmffs2;
fc-fsio won't work without this feature.  Try rebuilding with this
feature added and see if it starts working then.

> Didn't have chance to test this, but seems like FLASH2_BASE_ADDR is not
> defined anywhere, but I guess it should be 0x0180 ?

It is defined in cfgmagic/target.fcdev3b, from where it propagates
into the include/config.h generated file, which is then included by
all C source files.  And yes, 0x0180 is the correct FLASH2_BASE_ADDR
for the FCDEV3B and for all future FreeCalypso hw designs which will
use the same Spansion chip with the 2nd flash chip select connected to
Calypso nCS2 per Leonardo reference schematics.

M~
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

Didn't have chance to test this, but seems like FLASH2_BASE_ADDR is not
defined anywhere, but I guess it should be 0x0180 ?

struct dev_s dev = {
.base   = (char *) FLASH2_BASE_ADDR +
CONFIG_AFTERMARKET_FFS_START * 0x4,
.manufact   = MANUFACT_AMD,
.blocksize   = 0x4,
.blocksize_ld  = 18,
.driver   = FFS_DRIVER_AMD,
.numblocks   = CONFIG_AFTERMARKET_FFS_NBLOCKS,
};

On Wed, May 3, 2017 at 11:50 PM, Serg l  wrote:

> Didn't dig to much, but trying aftermarket-ffs or fcfam-ffs when
> Citrine is loaded via fc-xram results in following error from fc-fsio
>
> fsio> ls /
> opendir: FFS error 1 (EFFS_NODEVICE: flash device unknown)
>
> Rebooted into magnetite from flash shows normal content
> fsio> ls /
> .journal
> gsm
> pcm
> sys
> mmi
> var
> aud
> etc
>
> Startup log fragment
> RV 00010001 3 RVM: SWE list built success
> RV 00010001 3 RVM: trying to launch SWE 0x000A0010
> RV 00010001 5 RVM: SWE memory bank allocation success
> RV 000A0010 5 SPI : spi_set_info: try to init GLOBAL INFO SPI structure ...
> RV 00010001 5 RVM: SWE set info functions called
> RV 00010001 5 RVM: Created task nb  0x0003
> RV 000A0010 5 SPI_task: Initialization
> RV 00010001 5 RVM: Resumed task nb  0x0003
> RV 00010001 5 RVM: Resumed SWE  0x000A0010
> RV 00010001 5 RVM: SWE initialization success
> RV 00010001 3 create_RVtasks: SPI (0x000a0010) started
> RV 00010001 5 RVM: SWE START REQUEST 0x001E0004
> RV 00010001 2 rvm.SweHndlr.resolve_t2_grouping(), SWE Not type 2:
> 0x001E0004
> RV 00010001 3 RVM: SWE list built success
> RV 00010001 3 RVM: trying to launch SWE 0x001E0004
> RV 00010001 5 RVM: SWE memory bank allocation success
> RV 00010001 5 RVM: SWE set info functions called
> RV 00010001 5 RVM: Created task nb  0x0004
> RV 00010001 5 RVM: Resumed task nb  0x0004
> RV 00010001 5 RVM: Resumed SWE  0x001E0004
> RV 00010001 5 RVM: SWE initialization success
> RV 00010001 5 RVM: Resumed SWE  0x001E0004
> RV 00010001 5 RVM: SWE initialization success
> RV 00010001 3 create_RVtasks: ETM (0x001e0004) started
> RV 00010001 5 RVM: SWE START REQUEST 0x000A0002
> RV 00010001 2 rvm.SweHndlr.resolve_t2_grouping(), SWE Not type 2:
> 0x000A0002
> RV 00010001 3 RVM: SWE list built success
> RV 00010001 3 RVM: trying to launch SWE 0x000A0002
> RV 00010001 5 RVM: SWE memory bank allocation success
> RV 000A0002 3 RTC : rtc_set_info: try to init GLOBAL INFO RTC structure ...
> RV 00010001 5 RVM: SWE set info functions called
> RV 00010001 5 RVM: Created task nb  0x0005
> RV 00010001 5 RVM: Resumed task nb  0x0005
> RV 00010001 5 RVM: Resumed SWE  0x000A0002
> RV 00010001 5 RVM: SWE initialization success
> RV 000A0002 3 RTC: Initialization
> RV 00010001 3 create_RVtasks: RTC (0x000a0002) started
> GPF sysprim id=B7 ts=0025 SYST->TST "IS_STACK_TIME"
> GPF trace id=A7 ts=0025 SYST->PCO "&0"
> RV 000A0004 2 ffs_init() 0
> RV 000A0004 2 FFS revision: 0x5056
> RV 000A0004 2 FFS device, driver: 0x01, 0x, 2
> RV 000A0004 2 FFS base, blocks: 0x180, 8
> RV 000A0004 2 FFS format read, write: 0x210, 0x210
> GPF trace id=A7 ts=0098 SYST->PCO tc=05 "pei_init: no trace mask in
> FFS"
> GPF trace id=A7 ts=013A SYST->PCO "L1:em_l1_sem_index cleared"
> GPF trace id=A7 ts=013A SYST->PCO "DL version is FreeCalypso"
> GPF trace id=A7 ts=013A SYST->PCO "DL:em_dl_sem_index cleared"
> L1: > CPU 3 4
> L1: TST_C 3 TCS_2.1.1.14_L1_1454_0 FreeCalypso DSP:3606h DYN:6840h
> CHECKSUM:d278h
> RV 00010001 3 MEM STAT: Total memory required 0x3CD0
> RV 00010001 3 MEM STAT: Total memory obtained 0x3DD8
> RV 00010001 3 MEM STAT: Total memory used 0x4690
> RV 00010001 3 MEM STAT: Mem usage ratio  : 098.779419%
> RV 00010001 3 *** START DUMPING MEMORY BANK ***
> RV 00010001 3 **MB_NAME* Id Used_mem Watermark  Limit   Peak Nb_buff
> Avg_buf_size
> RV 00010001 3   RVM_PRIM  0  360  5900   6000548   0
> 67
> RV 00010001 3   RV_TRACE 59  952 25000  25000   3740   0
> 64
> RV 00010001 3 RVM_STACKS  6 7248  7948   7948   7248   0
>   1208
> RV 00010001 3RVM_SYS  7 1976  8900   9000   1976   0
> 93
> RV 00010001 3  RVM_TIMER  80  2500   3000  0   0
>  0
> RV 00010001 3 RVM_NOTIFY  90  2500   3000  0   0
>  0
> RV 00010001 3   FFS_PRIM 10   48  6216   9216 96   0
> 48
> RV 00010001 3   SPI_PRIM 11   24   200256 24   0
> 24
> RV 00010001 3   ETM_PRIM 128  1024   1024 48   0
> 32
> RV 00010001 3   RTC_PRIM 13   2080100 20   0
> 10
> RV 00010001 3 TOTAL:   10732**  64544  13700
> RV 00010001 3 *** START DUMPING MEMORY ***
> RV 00010001 3 Total memory available  0x000138AC
> RV 00010001 3 Memory currently in use 0x3168
> RV 00010001 3 *** START DUMPING TASKS ***
> RV 00010001 3 *TASK_NAME Id Stack_size 

Re: FCDEV3B bring-up status

[Serg l]

Didn't dig to much, but trying aftermarket-ffs or fcfam-ffs when
Citrine is loaded via fc-xram results in following error from fc-fsio

fsio> ls /
opendir: FFS error 1 (EFFS_NODEVICE: flash device unknown)

Rebooted into magnetite from flash shows normal content
fsio> ls /
.journal
gsm
pcm
sys
mmi
var
aud
etc

Startup log fragment
RV 00010001 3 RVM: SWE list built success
RV 00010001 3 RVM: trying to launch SWE 0x000A0010
RV 00010001 5 RVM: SWE memory bank allocation success
RV 000A0010 5 SPI : spi_set_info: try to init GLOBAL INFO SPI structure ...
RV 00010001 5 RVM: SWE set info functions called
RV 00010001 5 RVM: Created task nb  0x0003
RV 000A0010 5 SPI_task: Initialization
RV 00010001 5 RVM: Resumed task nb  0x0003
RV 00010001 5 RVM: Resumed SWE  0x000A0010
RV 00010001 5 RVM: SWE initialization success
RV 00010001 3 create_RVtasks: SPI (0x000a0010) started
RV 00010001 5 RVM: SWE START REQUEST 0x001E0004
RV 00010001 2 rvm.SweHndlr.resolve_t2_grouping(), SWE Not type 2:  0x001E0004
RV 00010001 3 RVM: SWE list built success
RV 00010001 3 RVM: trying to launch SWE 0x001E0004
RV 00010001 5 RVM: SWE memory bank allocation success
RV 00010001 5 RVM: SWE set info functions called
RV 00010001 5 RVM: Created task nb  0x0004
RV 00010001 5 RVM: Resumed task nb  0x0004
RV 00010001 5 RVM: Resumed SWE  0x001E0004
RV 00010001 5 RVM: SWE initialization success
RV 00010001 5 RVM: Resumed SWE  0x001E0004
RV 00010001 5 RVM: SWE initialization success
RV 00010001 3 create_RVtasks: ETM (0x001e0004) started
RV 00010001 5 RVM: SWE START REQUEST 0x000A0002
RV 00010001 2 rvm.SweHndlr.resolve_t2_grouping(), SWE Not type 2:  0x000A0002
RV 00010001 3 RVM: SWE list built success
RV 00010001 3 RVM: trying to launch SWE 0x000A0002
RV 00010001 5 RVM: SWE memory bank allocation success
RV 000A0002 3 RTC : rtc_set_info: try to init GLOBAL INFO RTC structure ...
RV 00010001 5 RVM: SWE set info functions called
RV 00010001 5 RVM: Created task nb  0x0005
RV 00010001 5 RVM: Resumed task nb  0x0005
RV 00010001 5 RVM: Resumed SWE  0x000A0002
RV 00010001 5 RVM: SWE initialization success
RV 000A0002 3 RTC: Initialization
RV 00010001 3 create_RVtasks: RTC (0x000a0002) started
GPF sysprim id=B7 ts=0025 SYST->TST "IS_STACK_TIME"
GPF trace id=A7 ts=0025 SYST->PCO "&0"
RV 000A0004 2 ffs_init() 0
RV 000A0004 2 FFS revision: 0x5056
RV 000A0004 2 FFS device, driver: 0x01, 0x, 2
RV 000A0004 2 FFS base, blocks: 0x180, 8
RV 000A0004 2 FFS format read, write: 0x210, 0x210
GPF trace id=A7 ts=0098 SYST->PCO tc=05 "pei_init: no trace mask in FFS"
GPF trace id=A7 ts=013A SYST->PCO "L1:em_l1_sem_index cleared"
GPF trace id=A7 ts=013A SYST->PCO "DL version is FreeCalypso"
GPF trace id=A7 ts=013A SYST->PCO "DL:em_dl_sem_index cleared"
L1: > CPU 3 4
L1: TST_C 3 TCS_2.1.1.14_L1_1454_0 FreeCalypso DSP:3606h DYN:6840h
CHECKSUM:d278h
RV 00010001 3 MEM STAT: Total memory required 0x3CD0
RV 00010001 3 MEM STAT: Total memory obtained 0x3DD8
RV 00010001 3 MEM STAT: Total memory used 0x4690
RV 00010001 3 MEM STAT: Mem usage ratio  : 098.779419%
RV 00010001 3 *** START DUMPING MEMORY BANK ***
RV 00010001 3 **MB_NAME* Id Used_mem Watermark  Limit   Peak Nb_buff
Avg_buf_size
RV 00010001 3   RVM_PRIM  0  360  5900   6000548   0
67
RV 00010001 3   RV_TRACE 59  952 25000  25000   3740   0
64
RV 00010001 3 RVM_STACKS  6 7248  7948   7948   7248   0
  1208
RV 00010001 3RVM_SYS  7 1976  8900   9000   1976   0
93
RV 00010001 3  RVM_TIMER  80  2500   3000  0   0
 0
RV 00010001 3 RVM_NOTIFY  90  2500   3000  0   0
 0
RV 00010001 3   FFS_PRIM 10   48  6216   9216 96   0
48
RV 00010001 3   SPI_PRIM 11   24   200256 24   0
24
RV 00010001 3   ETM_PRIM 128  1024   1024 48   0
32
RV 00010001 3   RTC_PRIM 13   2080100 20   0
10
RV 00010001 3 TOTAL:   10732**  64544  13700
RV 00010001 3 *** START DUMPING MEMORY ***
RV 00010001 3 Total memory available  0x000138AC
RV 00010001 3 Memory currently in use 0x3168
RV 00010001 3 *** START DUMPING TASKS ***
RV 00010001 3 *TASK_NAME Id Stack_size Used_stack
RV 00010001 3RVM  0   1500792
RV 00010001 3  TRACE  1   2000276
RV 00010001 3FFS  2   1024296
RV 00010001 3SPI  3   1000224
RV 00010001 3ETM  4   1024252
RV 00010001 3RTC  5700224
RV 00010001 3   RV_START 29   1024456
GPF trace id=A7 ts=0163 SYST->PCO "RR:em_rr_sem_index cleared"
GPF trace id=A7 ts=0163 SYST->PCO tc=05 "All tasks entered main loop"
L1: ADC_R 28
RV 000A0010 5 SPI: ADC are on
L1:   ADC :101 0
L1: > CPU 95 35

And here I connect fsio

*** Client program connected
L1:   ADC :2447 0
RV 000A0010 5 

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Hi Serg,

> It booted fine in mode 1, and sure thing it was rebooting without disabling
> sleep mode, even being connected to 5W linear PSU with highly stable 3.3V
> output

OK, so we know that the sleep mode reboot problem is not specific to
just my S/N 001 board.  My plan for trying to fix this problem is as
follows:

1. Desolder the JP2 and JP3 jumper headers and solder direct wire
   jumpers in their place, using the thickest wire gauge that will fit
   into the plated through holes on the PCB.  These current measurement
   jumpers are after the big capacitor at C323, and they are a feature
   not present on any of our pre-existing Calypso targets, so perhaps
   they could be a culprit.

2. If the above does not help, try upping the 0402 caps at C220 and
   C221 from 100 nF to 1 uF.  Openmoko devices work fine with 100 nF
   caps there and TI's Leonardo reference schematics indicate the same,
   but who knows...

I would love it if you could beat me to trying the above. :)

M~
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

Another report. I flashed the image built by Mychaela, booted from it and
re-entered VCXO calibration values into FFS via tmsh.
The MS registered with the network in one shot without any problems.
I was able to make and receive calls and SMS. I concluded this test by a
shot of whiskey in order to celebrate this milestone of the project.

The next step would be to try Citrine with the same FFS content.

-Serg

On Tue, May 2, 2017 at 1:23 PM, Mychaela Falconia <
mychaela.falco...@gmail.com> wrote:

> Serg wrote:
>
> > Last night I have compiled in my VCXO calibration values into
> > citrine/L1/cust0/l1_rf12.h and used fcfam load agent to do x-ram boot.
>
> Please remember that neither Citrine's build system nor that of
> Magnetite tracks header file dependencies, so if you edit a header
> file (as opposed to a directly compiled C module file) and rerun make
> in an already-compiled tree, it may not pick up your change - you may
> need to do at least a partial make clean in the area of change.  In
> the case of your change in Citrine, did you do a make clean at least
> in L1/cust0?
>
> > Still no joy locking on a network.
>
> Can you post your complete rvinterf session log?  If you send me your
> ssh public key and your preferred username, I'll make you a user
> account on freecalypso.org and you'll have a www-exported member
> directory through which you can post files.
>
> > rf_table afcparams
> > [numbers]
>
> Your numbers look good to me, they are in the same range of per-unit
> variation as observed on Openmoko-made GTA02 units.
>
> > Mychaela, could you share your fwimage.bin? Just would like to make sure
> > that I run known good build, free of config errors.
>
> https://www.freecalypso.org/members/falcon/fcdev3b/
> magnetite-build-20170502.tar.bz2
>
> Das Signal wrote:
>
> > A possible suggestion, consider trying the cell_log application:
> > Mychaela has reported success in sending a RACH and receiving an
> > IMMASS with the TA.
>
> Yes, that is correct.  I also tried their full mobile application and
> was able to send and receive SMS, and some voice calls too - the latter
> have always been unreliable for me with OsmocomBB software, even on
> pre-existing Calypso hardware.  During that weekend in April when I
> was preparing boards to ship to Serg and to Harald Welte, I tested all
> 8 boards, and for the RF test I used OsmocomBB as that was before I
> developed the manual calibration procedure for the VCXO.
>
> The point is that the board which I sent to Serg *was* tested on my
> end with OsmocomBB's mobile application, and it successfully connected
> to my local cell of Operator 310260 (T-Mobile USA).
>
> Later I developed that manual VCXO calibration procedure and performed
> it on my S/N 001 board (after Serg's and HW's boards already shipped
> out), and I am now able to connect to the same T-Mobile network with
> FC Magnetite (l1reconst config) from my S/N 001 board.  I have not
> tried FC Citrine yet, nor the TCS2/TCS3 hybrid config of Magnetite.
>
> M~
> ___
> 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

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Serg wrote:

> Last night I have compiled in my VCXO calibration values into
> citrine/L1/cust0/l1_rf12.h and used fcfam load agent to do x-ram boot.

Please remember that neither Citrine's build system nor that of
Magnetite tracks header file dependencies, so if you edit a header
file (as opposed to a directly compiled C module file) and rerun make
in an already-compiled tree, it may not pick up your change - you may
need to do at least a partial make clean in the area of change.  In
the case of your change in Citrine, did you do a make clean at least
in L1/cust0?

> Still no joy locking on a network.

Can you post your complete rvinterf session log?  If you send me your
ssh public key and your preferred username, I'll make you a user
account on freecalypso.org and you'll have a www-exported member
directory through which you can post files.

> rf_table afcparams
> [numbers]

Your numbers look good to me, they are in the same range of per-unit
variation as observed on Openmoko-made GTA02 units.

> Mychaela, could you share your fwimage.bin? Just would like to make sure
> that I run known good build, free of config errors.

https://www.freecalypso.org/members/falcon/fcdev3b/magnetite-build-20170502.tar.bz2

Das Signal wrote:

> A possible suggestion, consider trying the cell_log application:
> Mychaela has reported success in sending a RACH and receiving an
> IMMASS with the TA.

Yes, that is correct.  I also tried their full mobile application and
was able to send and receive SMS, and some voice calls too - the latter
have always been unreliable for me with OsmocomBB software, even on
pre-existing Calypso hardware.  During that weekend in April when I
was preparing boards to ship to Serg and to Harald Welte, I tested all
8 boards, and for the RF test I used OsmocomBB as that was before I
developed the manual calibration procedure for the VCXO.

The point is that the board which I sent to Serg *was* tested on my
end with OsmocomBB's mobile application, and it successfully connected
to my local cell of Operator 310260 (T-Mobile USA).

Later I developed that manual VCXO calibration procedure and performed
it on my S/N 001 board (after Serg's and HW's boards already shipped
out), and I am now able to connect to the same T-Mobile network with
FC Magnetite (l1reconst config) from my S/N 001 board.  I have not
tried FC Citrine yet, nor the TCS2/TCS3 hybrid config of Magnetite.

M~
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

Hi DS,

I will check cell_log with CMU200, it does generate BS signal, so I should
be able to catch it.

I followed calibration process for Margnetite and for Citrine I put my
custom values right into the source. Unless the CMU device I got is screwed
and gives me misleading numbers.

On Tue, May 2, 2017 at 9:47 AM, Das Signal 
wrote:

> Hi Serg,
>
> A possible suggestion, consider trying the cell_log application:
> Mychaela has reported success in sending a RACH and receiving an
> IMMASS with the TA.
>
> Also do you have the afcdac and afcparams files? I think Mychaela
> mentioned they are absolutely required for proper operation.
>
> --DS
> ___
> 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

Re: FCDEV3B bring-up status

[Das Signal]

Hi Serg,

A possible suggestion, consider trying the cell_log application:
Mychaela has reported success in sending a RACH and receiving an
IMMASS with the TA.

Also do you have the afcdac and afcparams files? I think Mychaela
mentioned they are absolutely required for proper operation.

--DS
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

Interesting! Possibly components quality issues or other variables...

Last night I have compiled in my VCXO calibration values into
citrine/L1/cust0/l1_rf12.h and used fcfam load agent to do x-ram boot.
Still no joy locking on a network.
rf_table afcparams

  3368  # Psi_sta_inv
15  # Psi_st
   1020152  # Psi_st_32
  4210  # Psi_st_inv

  1897  # DAC_INIT * 8
 -7748  # DAC_MIN * 8
  9129  # DAC_MAX * 8
  2560  # snr_thr

# DAC_INIT: rfpw 10 237


Mychaela, could you share your fwimage.bin? Just would like to make sure
that I run known good build, free of config errors.

-Serg


On Tue, May 2, 2017 at 12:42 AM, Mychaela Falconia <
mychaela.falco...@gmail.com> wrote:

> Hello FreeCalypso community,
>
> I've got an update on the flash boot problem, or rather several
> discoveries on that front.
>
> The first discovery is that of the 6 boards I have left after sending
> one to Harald Welte and another to Serg, the mysterious flash boot
> problem I've been seeing only occurs on one board, S/N 001 - it is the
> one on which I've been doing most of my work.  4 of the boards
> (S/N 002, 006, 007 and 008) boot flash fw images just fine, and the
> remaining one (S/N 004) is unable to boot the full fw at all -
> fc-loadtool etc work just fine, but if I try to load a full fw image
> via fc-xram, it goes through the download process and then hangs once
> the jump to the downloaded code has been made.  I suspect that it is
> some totally different problem from the flash boot issue on S/N 001.
>
> The second discovery is that the S/N 001 board which exhibits the
> mysterious flash boot problem only manifests the erratic behaviour
> when the fw image in the flash uses flash boot mode 1, and works just
> fine when it uses flash boot mode 0.  See the doc/Flash-boot-modes
> article I just added to the freecalypso-tools tree for the explanation
> of the two flash boot modes.  FC Citrine uses flash boot mode 0;
> unhacked FC Magnetite uses flash boot mode 1, but I just implemented
> an optional patch that makes it use flash boot mode 0, and the latter
> works on my S/N 001 board.
>
> To Serg: I encourage you to try building FC Magnetite for the FCDEV3B
> in the flash image configuration and flashing it into your board, to
> see if the board I sent you has working flash boot.  Build Magnetite
> for the fcdev3b target in the l1reconst configuration, do a regular
> make to get fwimage.bin, enter loadtool with fc-loadtool -h fcfam
> /dev/ttyXXX, and then flash it like this:
>
> flash erase 0 24
> flash program-bin 0 fwimage.bin
>
> I also made the change in the Magnetite source to enable MCSI pins at
> the pin multiplexing level for the FCDEV3B target, so if you hg pull
> this latest change, recompile fwimage.bin and flash it, you should be
> all set to start playing with MCSI - just issue an auw 0 2 command
> through fc-tmsh to enter the Bluetooth headset mode.  Citrine has had
> MCSI pins enabled at the pinmux level all along, but it does not have
> the Audio Service component for switching audio routing modes.  We
> previously discussed making Citrine do MCSI via a direct code change
> in L1 init, but I feel that it would be better to try MCSI in the
> known-good TI reference environment first.
>
> Going forward, I'm going to regard the mysterious flash boot issue as
> a non-problem until and unless we get reports of the problem happening
> on more boards than just my S/N 001.  With this mysterious problem out
> of the way, my main focus is now going to be on finishing the automated
> calibration software, so that I can calibrate all of the boards which
> are currently still in my hands and finally send them out to the
> anxiously-waiting community members.
>
> 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

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Hello FreeCalypso community,

I've got an update on the flash boot problem, or rather several
discoveries on that front.

The first discovery is that of the 6 boards I have left after sending
one to Harald Welte and another to Serg, the mysterious flash boot
problem I've been seeing only occurs on one board, S/N 001 - it is the
one on which I've been doing most of my work.  4 of the boards
(S/N 002, 006, 007 and 008) boot flash fw images just fine, and the
remaining one (S/N 004) is unable to boot the full fw at all -
fc-loadtool etc work just fine, but if I try to load a full fw image
via fc-xram, it goes through the download process and then hangs once
the jump to the downloaded code has been made.  I suspect that it is
some totally different problem from the flash boot issue on S/N 001.

The second discovery is that the S/N 001 board which exhibits the
mysterious flash boot problem only manifests the erratic behaviour
when the fw image in the flash uses flash boot mode 1, and works just
fine when it uses flash boot mode 0.  See the doc/Flash-boot-modes
article I just added to the freecalypso-tools tree for the explanation
of the two flash boot modes.  FC Citrine uses flash boot mode 0;
unhacked FC Magnetite uses flash boot mode 1, but I just implemented
an optional patch that makes it use flash boot mode 0, and the latter
works on my S/N 001 board.

To Serg: I encourage you to try building FC Magnetite for the FCDEV3B
in the flash image configuration and flashing it into your board, to
see if the board I sent you has working flash boot.  Build Magnetite
for the fcdev3b target in the l1reconst configuration, do a regular
make to get fwimage.bin, enter loadtool with fc-loadtool -h fcfam
/dev/ttyXXX, and then flash it like this:

flash erase 0 24
flash program-bin 0 fwimage.bin

I also made the change in the Magnetite source to enable MCSI pins at
the pin multiplexing level for the FCDEV3B target, so if you hg pull
this latest change, recompile fwimage.bin and flash it, you should be
all set to start playing with MCSI - just issue an auw 0 2 command
through fc-tmsh to enter the Bluetooth headset mode.  Citrine has had
MCSI pins enabled at the pinmux level all along, but it does not have
the Audio Service component for switching audio routing modes.  We
previously discussed making Citrine do MCSI via a direct code change
in L1 init, but I feel that it would be better to try MCSI in the
known-good TI reference environment first.

Going forward, I'm going to regard the mysterious flash boot issue as
a non-problem until and unless we get reports of the problem happening
on more boards than just my S/N 001.  With this mysterious problem out
of the way, my main focus is now going to be on finishing the automated
calibration software, so that I can calibrate all of the boards which
are currently still in my hands and finally send them out to the
anxiously-waiting community members.

Hasta la Victoria, Siempre,
Mychaela aka The Mother
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Hi Serg,

> Would like to share some experience trying to calibrate VCXO. I ran the
> manual process with CMU200 and everything went okay, just like Mychaela
> described. I got different numbers but within the same range and with
> similar trend.

Good!

> However an attempt to go against the live network did not
> work, the network was starting LUP and apparently could not decode bursts.

What do you mean by the network starting LUP?  The Location Update
procedure is initiated by the MS when it finds a good cell, not by the
network - the process starts with the MS sending a RACH to which the
network will reply with an Immediate Assignment.  Are you getting to
the point where the MS is sending out a RACH after having locked onto
the right cell in your area?  Does the RACH seem to be then ignored by
the network, leading you to the conclusion that the network is unable
to decode the bursts sent by the MS?  Or are you getting as far as the
dedicated channel establishment for the LUP, and then getting some
behavior that seems like bursts not being decoded correctly?

Do you have an rvinterf log that you can share?  (Remember, no mail
attachments on this list, please post a link instead.)

> So far I stopped any further attempts and will study CMU200 procedures how
> to setup proper BS simulation.

If you do this part, you will be ahead of me, as I haven't exercised
the CMU200's GSM signaling modes yet, only non-signaling.

> The unit I acquired seems to be in good working order and I have 10 MHz
> GPSDO connected to it as an external reference.

Just curious, is your GPSDO a Trimble Thunderbolt?  I used to be on
the time-nuts list, and the Thunderbolt was everyone's favorite GPSDO.

I don't have a GPSDO setup currently (I do have a Thunderbolt unit,
but no outdoor GPS antenna setup), so I'm running my CMU200 with its
internal timing reference.  But my unit does have the better of the
two OCXO options (called B12 IIRC), so I think it's probably good
enough.

M~
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

Would like to share some experience trying to calibrate VCXO. I ran the
manual process with CMU200 and everything went okay, just like Mychaela
described. I got different numbers but within the same range and with
similar trend. However an attempt to go against the live network did not
work, the network was starting LUP and apparently could not decode bursts.
So far I stopped any further attempts and will study CMU200 procedures how
to setup proper BS simulation.
The unit I acquired seems to be in good working order and I have 10 MHz
GPSDO connected to it as an external reference.

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 

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Serg wrote:

> Right now I'm doing a deep dive into the codebase to document some parts of
> it, it already replaced all my leisure time activities and I'm still
> looking for someone to do it for money... Yes, I cannot offer a lot, but it
> could be reasonable money for non-US based person. If anybody is
> interested, ping me here in the list.

You may have a better chance of finding someone who can do the software
work you need if you describe what it is you would want them to do. :)
If you post a description here of what software work you need done for
your special application, maybe one of our many lurkers could be
convinced to come out of the shy-land and try their hand at being a
FreeCalypso developer, especially if they might be able to earn some
money doing that.

> It would be great to find the root cause of the flash boot and sleep mode
> issues, but it is not a show stopper for my part of the project,

It is not a show-stopper for me either, but we need to address this
issue before I send out boards to everyone else who is waiting for
theirs, as the fix will likely require at least some physical rework
on the boards.

The development of the calibration software is another factor delaying
the shipment of boards to community members, as it would make a lot
more sense to have me calibrate the boards in my lab before shipping
them out than to expect every user to get their own CMU200.

When we get the calibration software done and I gain the ability to
ship out calibrated boards (i.e., with individual per-board calibration
values written in the flash file system), I will also make a backup of
each board's calibration on my end before shipping, thus if you corrupt
your FFS, all you'll need to do will be to ask for a copy of your
calibration backup by email - no need to ship the board back for
recalibration or to acquire your own calibration station setup.  And
yes, the boards have serial numbers and I do keep track of which S/N I
sent to whom.

> I'm already very happy with the results FC got up to this point.

And I am definitely very happy to hear that. :)

> I'll tackle MCSI test activity and I think that I will start at some point
> in about two weeks from now, cannot promise any earlier.

It will definitely take me more than 2 weeks to finish the calibration
software and to investigate the flash boot and power supply issues, so
if you can get to MCSI before I do, we will have achieved some
parallelism. :)

M~
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

Hi All,

I have CMU200 on the way and hope that it is a good working unit as claimed
by the source. I also have GPS disciplined 10MHz ref clock, so I hope that
it makes up a proper calibration station. Said so I will be happy to
validate any RF calibration procedures and help with further development up
to my ability to carve out time for it.

Right now I'm doing a deep dive into the codebase to document some parts of
it, it already replaced all my leisure time activities and I'm still
looking for someone to do it for money... Yes, I cannot offer a lot, but it
could be reasonable money for non-US based person. If anybody is
interested, ping me here in the list.

It would be great to find the root cause of the flash boot and sleep mode
issues, but it is not a show stopper for my part of the project, I'm
already very happy with the results FC got up to this point.

I'll tackle MCSI test activity and I think that I will start at some point
in about two weeks from now, cannot promise any earlier.

-Serg

On Mon, Apr 24, 2017 at 2:57 PM, Mychaela Falconia <
mychaela.falco...@gmail.com> wrote:

> Hi DS,
>
> > This is an excellent suggestion and I did just that, using a board from
> > pldkit. It works very well and I wrote a README for those interested in
> > doing the same. Please have a look at
> >
> > https://www.freecalypso.org/members/ds/ftdi/
>
> Thank you for implementing my idea.  I am going to update
> doc/High-speed-serial in freecalypso-tools with this additional
> option, and include a link to your implementation.
>
> Meanwhile, I am still working on developing an automated process for
> production RF calibration of FreeCalypso hardware devices starting
> with FCDEV3B.  The VCXO calibration which I've done manually on one of
> the FCDEV3B boards is just the first step, the complete calibration
> process required for a fully spec-compliant product also includes Rx
> and Tx calibration for each band, and even the VCXO step alone is too
> much of a pain to do manually for every board, hence I need to develop
> automated calibration before I can finally send a properly calibrated
> board to everyone who is waiting for one.
>
> If you look in the freecalypso-tools repository, you will find that I
> wrote a bunch of calibration-related notes under doc/RF-cal.  You may
> find them to be interesting reading if you are curious about the
> calibration adventure.
>
> I am using the CMU200 as my choice of RF test station; I started by
> operating it manually through the front panel and that is how I got
> that manual VCXO calibration done, but I am now learning how to
> operate it programmatically so I can automate the process.  The
> industry standard way of controlling such instruments is through GPIB,
> but one nice thing about the CMU200 is that it supports not only the
> classic GPIB way, but also offers the option of control via SCPI
> commands over RS-232.  I chose the RS-232 option to eliminate the need
> for exotic hardware and equally exotic drivers and libraries - with
> RS-232 I can just write plain old C code without any library
> dependencies that talks to a serial port.
>
> I have now learned enough CMU200 SCPI commands to make frequency
> offset measurements for the VCXO calibration step and to run its RF
> signal generator (will be needed for the next step of Rx calibration),
> and now I am starting to implement the code that will test this
> knowledge.  I started writing the fc-cmu200d Test System Interface
> Daemon that will talk to the CMU200 via RS-232 and present a local
> socket interface with higher-level commands; the actual calibration
> automation programs will then connect to the latter interface - see
> the doc/RF-cal/Architecture write-up.
>
> I need to finish this fc-cmu200d (right now it is just a skeleton,
> none of the actual functionality has been added yet), test it manually
> with a netcat-like tool talking to its local UNIX domain socket, and
> only then we shall reach the point of being able to write the first
> automated calibration program for the VCXO step - and then the other
> two calibration steps (Rx bands and Tx bands) still need to be
> learned...  So there is still a ton of work to be done, and I
> guesstimate that it may take me another month or two with the limited
> time budget I have for this project - like most people, I have an
> entirely separate job to pay my bills.
>
> Aside from RF calibration, we still have the mysterious flash boot
> issue on our boards, as well as a power supply issue that requires us
> to disable sleep as a workaround.  I suspect that the current
> measurement jumpers in the VBAT path may be the culprit.  I added
> those jumpers with the idea of being able to characterize the current
> draw of the chipset and of the RF PA at different VBAT voltages, in
> order to support various kinds of powering arrangements in potential
> future FreeCalypso products, but these inserted jumpers in the power
> current path may be causing a problem - 

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Hi DS,

> This is an excellent suggestion and I did just that, using a board from
> pldkit. It works very well and I wrote a README for those interested in
> doing the same. Please have a look at
>
> https://www.freecalypso.org/members/ds/ftdi/

Thank you for implementing my idea.  I am going to update
doc/High-speed-serial in freecalypso-tools with this additional
option, and include a link to your implementation.

Meanwhile, I am still working on developing an automated process for
production RF calibration of FreeCalypso hardware devices starting
with FCDEV3B.  The VCXO calibration which I've done manually on one of
the FCDEV3B boards is just the first step, the complete calibration
process required for a fully spec-compliant product also includes Rx
and Tx calibration for each band, and even the VCXO step alone is too
much of a pain to do manually for every board, hence I need to develop
automated calibration before I can finally send a properly calibrated
board to everyone who is waiting for one.

If you look in the freecalypso-tools repository, you will find that I
wrote a bunch of calibration-related notes under doc/RF-cal.  You may
find them to be interesting reading if you are curious about the
calibration adventure.

I am using the CMU200 as my choice of RF test station; I started by
operating it manually through the front panel and that is how I got
that manual VCXO calibration done, but I am now learning how to
operate it programmatically so I can automate the process.  The
industry standard way of controlling such instruments is through GPIB,
but one nice thing about the CMU200 is that it supports not only the
classic GPIB way, but also offers the option of control via SCPI
commands over RS-232.  I chose the RS-232 option to eliminate the need
for exotic hardware and equally exotic drivers and libraries - with
RS-232 I can just write plain old C code without any library
dependencies that talks to a serial port.

I have now learned enough CMU200 SCPI commands to make frequency
offset measurements for the VCXO calibration step and to run its RF
signal generator (will be needed for the next step of Rx calibration),
and now I am starting to implement the code that will test this
knowledge.  I started writing the fc-cmu200d Test System Interface
Daemon that will talk to the CMU200 via RS-232 and present a local
socket interface with higher-level commands; the actual calibration
automation programs will then connect to the latter interface - see
the doc/RF-cal/Architecture write-up.

I need to finish this fc-cmu200d (right now it is just a skeleton,
none of the actual functionality has been added yet), test it manually
with a netcat-like tool talking to its local UNIX domain socket, and
only then we shall reach the point of being able to write the first
automated calibration program for the VCXO step - and then the other
two calibration steps (Rx bands and Tx bands) still need to be
learned...  So there is still a ton of work to be done, and I
guesstimate that it may take me another month or two with the limited
time budget I have for this project - like most people, I have an
entirely separate job to pay my bills.

Aside from RF calibration, we still have the mysterious flash boot
issue on our boards, as well as a power supply issue that requires us
to disable sleep as a workaround.  I suspect that the current
measurement jumpers in the VBAT path may be the culprit.  I added
those jumpers with the idea of being able to characterize the current
draw of the chipset and of the RF PA at different VBAT voltages, in
order to support various kinds of powering arrangements in potential
future FreeCalypso products, but these inserted jumpers in the power
current path may be causing a problem - the power supply current has
to go through these jumpers, they may be adding too much resistance,
and these inserted jumpers are after the big 1000 uF capacitor.

Right now the inserted current measurement jumpers take the form of a
two-post header with a shorting block placed on the pins, and I wonder
if this arrangement may be adding more resistance into the VBAT
current path than is allowed.  One of my planned experiments is to
remove the header pins and solder jumper wires directly into the
corresponding plated through holes on the PCB, using the thickest
gauge wire that will fit into those holes, and see if this change
improves the situation.  But I would like to get a better insight as
to exactly what happens during flash boot on our boards in their
present state before I try any hw modifications, in order to do that I
would like to experiment with JTAG, and for that I am waiting for some
"dupont" jumper wires (female to female) to arrive from Hong Kong.  I
could probably find the needed jumper wires more locally (and thus
faster) with some looking, but right now I am not in a hurry on that
front as the RF calibration software development work still needs to
be done no matter what, and it is not blocked by the 

Re: FCDEV3B bring-up status

[Das Signal]

On Mon, Apr 17, 2017 at 10:04:03AM -0800, Mychaela Falconia wrote:

> As another alternative to dirtying your kernel with a non-upstreamable
> patch that breaks things for other people who use 230400, 460800 or
> 921600 baud, I just thought of the following idea:
> 
> * Reprogram the EEPROM on your FreeCalypso FT2232D adapter to give it
>   some VID:PID which the standard ftdi_sio driver won't recognize and
>   won't attach to.  The EEPROM is off-chip and optional with FT2232D,
>   but the adapter boards from pldkit.com which I use and recommend do
>   have it.
> 
> * Make a copy of the ftdi_sio driver and build it outside of the Linux
>   kernel tree (i.e., make it an out-of-tree module) under a different
>   name.  Make it bind to the FreeCalypso FT2232D VID:PID you have
>   picked, and have this special out-of-tree driver version remap baud
>   rates like my current patch does.
> 
> * Voila - your actual kernel is now completely pristine, and I would
>   think that loading a custom out-of-tree USB driver module that has
>   proper GPL status (no taint in that regard) and does not touch
>   anything except the special USB VID:PID you have made up for
>   FreeCalypso use should not count as tainting your system.

Hi Mychaela,

This is an excellent suggestion and I did just that, using a board from
pldkit. It works very well and I wrote a README for those interested in
doing the same. Please have a look at

https://www.freecalypso.org/members/ds/ftdi/

--DS
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Hi Serg,

> Just a quick report that I received the board and was able to load a fresh
> build of magnetite from the repo into xram.

Awesome!

> The next step would be to perform calibration.

Have fun! :-)

> I see that in order to run high baud rate of the serial interface a driver
> patch is needed.

Either that, or use a CP2102 adapter on which you would only need to
program the EEPROM once.  I use FT2232D because for my area of interest
(full classic modem functionality) I would like to connect both UARTs
and using a single USB device for the two UARTs is better for sanity,
but if you only need to connect one UART (for what you are doing having
just RVTMUX should be sufficient), then CP2102 becomes an attractive
option.

If you would like to try the CP2102 route, there are CP2102 adapters
sold on ebay with the 3.3V serial interface brought out on male header
pins, so you would connect that adapter to FCDEV3B in exactly the same
way as how you must have done it with the FT2232D adapter board I sent
you.  You would need to program the CP2102 EEPROM per the instructions
in OsmocomBB wiki.

> 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.

If you send me your ssh public key and your preferred username, I'll
create you an account on the freecalypso.org server that comes with a
member web directory where you can upload stuff you'd like to publish:
anything you upload to /var/www/members/ will appear on
the web server under /members//.  You can then create
whatever packages you like in whatever format you like, upload them
there, and share the URL with the community.

M~
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

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.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 

Re: FCDEV3B bring-up status

[Serg l]

This is really good that you confirmed RF circuit functionality to some
degree.
I remember that you were talking about calibration procedures, could you
remind me where in the available docs and codebase we have the calibration
table values defined/described? Just trying not to duplicate the research
effort :) Maybe I could use some alternative tools than CMU200.

On Sun, Apr 9, 2017 at 3:59 AM, Mychaela Falconia <
mychaela.falco...@gmail.com> wrote:

> Hello again everyone,
>
> Just to assure myself that the RF tract on our FCDEV3B is fine in
> hardware terms and that our only problem in this regard is the lack of
> VCXO calibration, I have run OsmocomBB's full mobile app with their
> layer1 running on our FCDEV3B, with a real SIM in the SIM socket on
> our board, and it works: I was able to connect to my local GSM network
> (Operator 310260), and send and receive SMS successfully.  I have also
> succeeded in dialing and connecting a voice call, although I couldn't
> test the voice path as the off-board loudspeaker and microphone have
> not been added yet.
>
> When it comes to audio, I designed the FCDEV3B with the intent of being
> able to make test calls from the lab bench without needing anything
> except the board itself, and for this purpose there is a loudspeaker
> driver circuit and a microphone input circuit on the board.  However,
> the actual loudspeaker and microphone themselves aren't on the board,
> instead there are headers meant for connecting them.  At some point I
> will need to acquire some loudspeaker and microphone parts, wire them
> up to the headers and test these on-board audio circuits, but right
> now there are higher priorities.
>
> For me the bring-up priorities going forward are as follows:
>
> 1. Get to the bottom of the flash boot mystery.  We are not OsmocomBB
> and our firmware is meant to run from flash, hence the flash boot
> problem needs to be solved before I will feel comfortable taking on
> other major challenges like calibration.  In order to gather more
> insight into this flash boot mystery, I need to connect JTAG to our
> board, and I am currently missing the necessary jumper wires.  I need
> jumper wires like these:
>
> http://www.ebay.com/itm/262158878688?_trksid=p2057872.
> m2749.l2649=STRK%3AMEBIDX%3AIT
>
> I already placed the order for the above back on Wednesday, but the
> seller warns that they may take a month to arrive.  In the next few
> days I will see if I can procure similar jumper wires more locally.
>
> 2. Climb the calibration learning curve and get our FCDEV3B's VCXO
> calibrated on the CMU200 so we can bring up the GSM radio using our
> preferred firmware, rather than OsmocomBB.
>
> 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

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Hello FreeCalypso community,

After running a few more tests I reached the conclusion that the most
likely reason why our FCDEV3B running FC Magnetite fw is currently
unable to connect to a live commercial GSM network is not because of
some physical problem with the RF tract, but simply because of the
lack of calibration for the VCXO.  I have reached this conclusion
based on the following observations:

1. Serg and Harald asked me to try running OsmocomBB on this board.  I
   did as they asked (when running OsmocomBB on the FCDEV3B, use the
   gta0x version of layer1.highram.bin, *not* any of the compal ones -
   the gta0x build works unchanged on the FCDEV3B), and it appears to
   work.  I did not take it as far as running the full mobile app (I
   may try it next), but I ran their cell_log app, and it found the
   local cells of Operator 310260, and reported the TA for each of
   them.  Finding the TA requires sending a RACH and getting an IMM ASS
   back, thus having cell_log work to this extent indicates that the
   RF tract on the FCDEV3B must be good in both Rx and Tx directions!

2. As an experiment, I fully erased the FFS on a GTA02 modem,
   reinitialized it with just /etc/IMEISV and /gsm/com/rfcap (no RF
   calibration files), and tried connecting to the network.  Result:
   it fails in exactly the same way as our FCDEV3B currently does.
   When I restored the afcdac and afcparams files under /gsm/rf and
   rebooted, the modem happily connected to my local cell - thus it is
   the VCXO calibration that's critical here, not any other Rx or Tx
   calibration parameters.

Now here are the two big questions to which I have no answers:

1. The AFC algorithm used by OsmocomBB looks totally different from
   the one used by TI's TCS211 fw, and I am not enough of a guru to
   understand the differences between the two or their relative
   merits.  OsmocomBB's version does not require calibration and has
   no provision for making use of such, whereas TI's version expects
   that each MS gets individually calibrated on the production line.

   Doing per-unit calibration on production lines requires time and
   special equipment, i.e., money.  I figure that the mainstream
   manufacturers would not be doing such per-unit calibration if it
   could be avoided, hence there must be some good reason for doing
   this calibration.  But if so, then how is OsmocomBB able to get
   away with having no calibration provisions at all?

2. When we run our FreeCalypso firmwares on Mot C1xx phones, we don't
   have any calibration values (Compal did not use TI's standard
   format, and we don't know how to grok their proprietary one), yet
   our firmwares running on these targets connect to GSM networks just
   fine.  But the very same sans-calibration configuration with the
   same fw fails on GTA02 and FCDEV3B hardware!

Just to be clear, the purpose of the FCDEV3B is to run TCS211 or
TCS2/TCS3 hybrid firmware in its full glory.  Running OsmocomBB on the
FCDEV3B is certainly possible, but pointless: right this moment there
are 29 listings on ebay for Mot C139 phones, with prices in the $5 to
$20 range, and for OsmocomBB our FCDEV3B offers absolutely no advantage
over these obscenely cheap Mot C1xx phones, hence buying a very
expensive board like ours only to run OsmocomBB would be a waste of
money.  Instead the purpose of our board is run TI's TCS211 fw in its
full glory with CSD, fax and GPRS services, which is not possible on
Mot C1xx phones.

Hence in order to achieve our goal of running the firmware we like, it
looks like we will have to bite the bullet and calibrate our boards on
the CMU200 before we'll able to connect to GSM networks using our
choice of fw.  Climbing the very steep learning curve of the CMU200
and of the calibration procedures is now on my to-do list.

Hasta la Victoria, Siempre,
Mychaela aka The Mother
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Mychaela Falconia]

Serg wrote:

> I do have a bench PSU with variable output. I would also try to use battery
> option, it may produce slightly different pattern of current when radio is
> turned on because it has different internal resistance than a PSU.
> Working platform is a pre-requisite for any future work we have planned, so
> investigating of L1 issue would be the first priority here.

Very well then - assuming that no other issues come up this weekend,
I'll be sending you a board with Monday's mail or UPS run.  Please
send me your shipping address off-list.

The power input connector on the board is Weidmuller 151046; I
currently use Weidmuller 171633 as the mating connector, but there
are several choices here.

M~
___
Community mailing list
Community@freecalypso.org
https://www.freecalypso.org/mailman/listinfo/community

Re: FCDEV3B bring-up status

[Serg l]

I do have a bench PSU with variable output. I would also try to use battery
option, it may produce slightly different pattern of current when radio is
turned on because it has different internal resistance than a PSU.
Working platform is a pre-requisite for any future work we have planned, so
investigating of L1 issue would be the first priority here.

On Wed, Apr 5, 2017 at 11:36 AM, Mychaela Falconia <
mychaela.falco...@gmail.com> wrote:

> Serg wrote:
>
> > I'm anxious to bring it into our RF lab.
> > I expect to have some time available to look into L1 in upcoming weeks.
>
> I should be able to send you a board with Monday's mail, after I get
> all 8 boards to my home lab this coming weekend and make sure that all
> 8 work to the same extent.  I'll be able to include a generic
> off-the-shelf FT2232D breakout board as well (the same kind that I
> use), but you will need to make your own jumper wires with crimp-on
> female sockets on both ends to go from the male header pins on the
> FCDEV3B to similar male header pins on the FT2232D board.
>
> For power, do you have a bench power supply that can put out 3.6 VDC?
> If so, I can send you a cable that has the right Weidmuller connector
> for the FCDEV3B on one end and a pair on banana plugs on the other end.
>
> The same goes for everyone else on the list: if you are both able and
> willing to help hands-on with the debugging of the issues we are having
> and with bringing up the RF tract on the FCDEV3B, you can also get one
> of the boards.
>
> If anyone here would like to receive a board, please indicate what
> specifically you are going to do if and when you receive one: given
> the limited supply of boards, I would like the first ones to go to
> people who would actually help with the debugging and bring-up in some
> real tangible way, rather than just stare at the board and put it away
> to gather dust.
>
> > I was also curious if we load OsmocomBB into it and see what will it
> say...
>
> I'm adding it to my list of steps to try this Saturday when I come
> home with the boards.
>
> M~
> ___
> 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