FreeCalypso > hg > freecalypso-tools

comparison doc/SIM-hardware-debugging @ 461:10e168596dfd

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/SIM-hardware-debugging: article written
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 10 Feb 2019 20:40:56 +0000
parents
children 0f138858ff39
comparison
equal deleted inserted replaced
460:9b7ce2023355 461:10e168596dfd
1 This article is only going to be of interest to those who are physically
2 producing Calypso-based hardware and therefore get to deal with the joys of
3 yield troubleshooting and failure analysis. If you are a mere user or software
4 developer working on known-good hardware made by someone other than you, then
5 none of the following applies to you.
6
7 Testing the SIM interface on a Calypso device
8 =============================================
9
10 A basic pass/fail test of the SIM interface is quite straightforward: simply
11 insert a test SIM into the socket (at FreeCalypso hw manufacturing we currently
12 use Sysmocom SIMs for this purpose) and issue an AT+CFUN=1 command to the
13 standard firmware; if the SIM interface hardware is good, the command will
14 complete successfully with an OK response, otherwise it will throw up an error.
15
16 But what do you do when this basic test fails? If you get a "SIM not inserted"
17 error even though the SIM *is* in fact inserted, how do you debug it further?
18 In order to facilitate lower-level debugging of SIM interface woes, we have
19 implemented a standalone simtest program described in this article. To run
20 this simtest program on your Calypso device, run an fc-iram command like this:
21
22 fc-iram -h fcfam /dev/ttyXXX /opt/freecalypso/target-bin/simtest.srec
23
24 Like other interactive programs in our target-utils suite, this simtest program
25 will present a '=' prompt for you to type further commands. The following
26 sequence of commands should bring up the SIM interface if the hardware is good:
27
28 abbinit
29 volt 1.8
30 setup
31 poll on
32 reset 1
33
34 You can change volt 1.8 to volt 3 if needed, but all recently made SIMs prefer
35 1.8 V and merely tolerate higher voltages. TI's Iota ABB chip, which is what
36 we target in FreeCalypso, does not support 5V SIMs - it doesn't have a charge
37 pump or any other boost converter to produce 5 V from lower battery voltages.
38 (It is not just TI but all mobile chipset vendors; it has been a very long time
39 since anyone made a phone that can power 5V SIMs, and any old 5V-only SIMs have
40 thus stopped being usable just as long ago.)
41
42 If the hardware is good and you have a working SIM inserted in the socket as
43 you execute the above commands, you should see ATR bytes from your SIM appear
44 in your terminal window the moment you issue the last reset 1 command: that
45 final command transitions the SIM reset line from low to high, if the SIM has
46 been given good power and clock prior to this event, this transition causes it
47 to initialize and emit its Answer To Reset, and once you issue the poll on
48 command, our simtest programs listens for incoming bytes from the SIM at the
49 same time while it listens for you to type further commands.
50
51 If you execute the above command sequence with a known-good SIM inserted in the
52 socket and you don't see any ATR bytes on the final reset 1 command, then you
53 have confirmed with a lower-level tool that your SIM interface hardware is
54 having some issues. Give it a poweroff command, rerun the fc-iram command to
55 get a fresh session, and get your oscilloscope ready. Now execute the commands
56 slowly, probing with your o'scope at each step:
57
58 abbinit
59 volt 1.8
60
61 The volt command enables the VRSIM regulator in the Iota ABB chip and causes it
62 to put out the selected voltage. You should see this voltage appear on SIM
63 socket contact C1 (VCC); if it fails to appear there, then trace out the circuit
64 coming from VRSIM, and the VRSIM regulator itself (inside the chip) may also be
65 suspect.
66
67 setup
68
69 This command puts the SIM interface block inside the Calypso into a sensible
70 state and enables the SIM interface level shifters in the Iota ABB. After this
71 command you should see a good 3.25 MHz clock (13 MHz divided by 4) with selected
72 SIM voltage levels on the SIM CLK line (socket contact C3), the RST line (socket
73 contact C2) should be low, and the I/O line (socket contact C7) should be high.
74 The SIM clock is produced in the Calypso and then voltage-translated by a
75 unidirectional buffer in the Iota ABB, thus if the clock fails to appear at the
76 SIM socket, look for issues in that signal path. For the I/O line to be high
77 at this point in the bring-up sequence, the resistor pull-ups on both DBB-to-ABB
78 and ABB-to-socket sides need to be working; if the I/O line is high on the
79 DBB-to-ABB side and the pull-up on the ABB-to-socket side is good, but the I/O
80 line on the ABB-to-socket side is still low, then there may be something wrong
81 with the level shifter in the ABB holding it low.
82
83 poll on
84 reset 1
85
86 (The poll on command can be omitted if you are doing o'scope probing on an empty
87 socket and thus not expecting any ATR.) As you issue that reset 1 command, hold
88 your oscilloscope probe on SIM socket contact C2, which is the RST line - it
89 should go from low to high. Our simtest utility's reset command (reset 0 or
90 reset 1) manipulates one bit in one Calypso register that controls the Calypso
91 chip's SIM_RST output, which then passes through a unidirectional level shifter
92 in the Iota ABB on its way to SIM socket contact C2.
93
94 On those two FCDEV3B V2 boards that have been rejected as defective because of a
95 non-working SIM interface and which are now being revisited for a more thorough
96 investigation, we have not yet seen any problems with the SIM power supply
97 voltage, with the SIM CLK line or with the I/O line pull-up, but on both boards
98 the SIM RST line is not working: we see a constant low at socket contact C2
99 (the only probe-able point in the entire SIM reset signal path), and reset 1
100 produces no effect. Unfortunately there is no way to probe the DBBSRST signal
101 going from Calypso to Iota (it goes from one BGA to the other on an inner layer
102 without coming up to the surface except right under the two ball pads), thus it
103 is too difficult to tell where the breakage occurs: is it the Calypso failing
104 to put out a high on its SIM_RST output when commanded to do so by the register
105 setting, is it some fault in the PCB shorting this signal to GND before it
106 reaches Iota's DBBSRST input, is it some fault inside the Iota chip itself that
107 causes it to put out a low on its SIMRST output even though the DBBSRST input
108 is high, or is it some fault in the PCB shorting the ABB-to-socket SIM RST
109 output to GND?
110
111 Given that FCDEV3B is not intended to be a high-volume product (we only need to
112 make enough good boards to provide one to every interested developer or
113 tinkerer), it will probably make more economic sense to simply reject SIM-
114 defective boards and write them off as a loss than to spend astronomical amounts
115 on PCB microsurgery to expose the DBBSRST signal for probing or other in-depth
116 troubleshooting measures along those lines. For future board designs that may
117 need to be produced in higher volumes, the Mother's current plan is to add
118 probe-able test points on DBBSCK and DBBSRST lines, so that if similar problems
119 recur, we'll be able to quickly isolate them to the Calypso side or the Iota
120 side.