FreeCalypso > hg > freecalypso-docs

comparison GTM900-design-guide @ 30:658010a51ff4

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
GTM900-design-guide written
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 13 Sep 2020 21:36:17 +0000
parents
children
comparison
equal deleted inserted replaced
29:6d7486db31cb 30:658010a51ff4
1 As of this writing (2020-09), the Mother's company Falconia Partners LLC is
2 actively in the process of bringing to market a new FreeCalypso hardware
3 solution based on our FC Tango module, and we also have an FTDI-based
4 (specifically FT2232D) adapter for connecting to Calypso UARTs (both of them)
5 and for controlling the Calypso module's PWON and RESET, allowing remote
6 control of Calypso power and boot in physically unattended environments.
7 However, this Tango-based solution is expected to become available some time
8 in 2020-12 (up to 3 months from now), and we realize that some people may not
9 be able to wait this long - some people may have an immediate need for some
10 working solution right now.
11
12 We are also aware that our European colleagues over at Sysmocom are working on
13 a competing solution based on the Huawei GTM900 Calypso modem module, but are
14 going totally the wrong way about it, and seem to be running into roadblocks
15 resulting from their earlier bad design choices. In light of this observed
16 situation, the present document has been put together to provide some guidance
17 to those who are currently misguided. If someone needs a working solution
18 right now, cannot wait another 3 months for our company to deliver our Tango-
19 based Caramel2+DUART28 solution, is looking at using GTM900 for the Calypso
20 module, and would be willing to use an FT2232x (either D or H) chip instead of
21 Sysmocom's poor choice of Silabs CP2105, this document will tell you exactly how
22 you should hook everything up in order to produce a guaranteed-working solution
23 without wasting time and energy on multiple design iterations.
24
25 FT2232x chip and EEPROM
26 =======================
27
28 Either FT2232D or FT2232H should work equally well, hence the choice between
29 the two is up to the board designer's preference. Our DUART28 adapter uses
30 FT2232D, and this choice was made primarily in the hope of easing the onerous
31 requirement of PCB controlled impedance (90 ohm differential) for USB traces:
32 FT2232H supports USB high speed, and this USB HS capability is thought to make
33 the controlled impedance requirement more stringent. Our competitor CP2105 has
34 no USB HS capability just like FT2232D, hence the latter was chosen to match.
35 But if the 90 ohm controlled impedance requirement is not a problem for you,
36 then by all means go ahead and use the newer and apparently more popular
37 FT2232H.
38
39 Whichever FT2232x chip you choose, you should include an EEPROM in your board
40 design. This EEPROM is officially optional per FTDI, but if you omit it, you
41 lose the ability to set a custom USB VID:PID. If you are only interested in
42 the two Calypso UARTs and don't need programmatic control of PWON and RESET,
43 then using the FT2232x chip's default USB VID:PID of 0x0403:0x6010 (with or
44 without an EEPROM) is perfectly fine. However, if you are going to do what I
45 recommend below in terms of using (otherwise unused) FT2232x Channel B RTS and
46 DTR outputs to control PWON and RESET, then you will need to apply a custom
47 patch to the Linux kernel's ftdi_sio driver (see freecalypso-hwlab Hg
48 repository) in order to make this mechanism practically usable. If you are
49 going to be applying any kind of custom patches to that ftdi_sio driver, having
50 a custom USB VID:PID will be very helpful in order to apply the needed quirks
51 conditionally, hence the EEPROM becomes necessary.
52
53 LEGAL NOTE: Falconia Partners LLC has received an official allocation of 8 PIDs
54 from FTDI out of FTDI's USB VID, but these USB IDs are _ONLY_ for hardware
55 products that are physically produced by Falconia Partners LLC - other parties
56 may not use these USB IDs without our explicit permission. Therefore, if you
57 are going to use a custom USB VID:PID, you will need to provide your own.
58
59 Dual UART signal connections
60 ============================
61
62 Unlike CP2105, the two channels of FT2232x are perfectly symmetric, hence the
63 choice of which FT2232x channel should be connected to which Calypso UART is
64 arbitrary. As the Mother of FreeCalypso, I very strongly encourage everyone to
65 use this convention: Calypso MODEM UART (the one for which Huawei brought out 8
66 wires with full modem control) should be connected to FT2232x Channel A, and
67 Calypso IrDA UART (the one for which there are only two wires) should be
68 connected to FT2232x Channel B.
69
70 If you are going for the lowest cost in terms of component count and PCB real
71 estate, it is perfectly acceptable to connect FT2232x I/O pins directly to
72 Calypso UART pins. Yes, FT2232x outputs operate at 3.3V and cannot be brought
73 down to Calypso native 2.8V, but if you read TI Calypso datasheets (document
74 CAL000/A in particular), is says quite clearly that input voltages of up to
75 VDDS+0.5V are acceptable, i.e., the inputs are tolerant of 3.3V. This situation
76 becomes a little less than ideal during Calypso sleep modes (the higher voltage
77 feeds into the chipset's V-IO rail and brings that rail a little higher than
78 normal), but engineering is all about trade-offs and compromises, and sometimes
79 it is necessary to trade off between perfection and cost.
80
81 If you do wish to feed proper 2.8V signals to the Calypso instead of 3.3V, the
82 easiest way to do so would be to insert LVC buffers into signal paths from
83 FT2232x outputs to Calypso UART inputs. Power the LVC buffer IC from the
84 Calypso+Iota chipset's V-IO rail, which Huawei brought out on an interface pin
85 they named "VDD". There will be no problem with partial power-down conditions
86 (USB on, Calypso off) because LVC buffers are specifically designed for such
87 operation and have very low Ioff specs in the uA range.
88
89 Our DUART28 adapter also includes another LVC buffer going the other way, in
90 the path from Calypso UART outputs to FT2232x inputs, but it is included for
91 only one reason: in order to gracefully support the other partial power-down
92 scenario of Calypso up and running, but no USB host connected and thus no USB
93 power. If this latter scenario is not a concern for your application, then
94 there is absolutely no problem with connecting Calypso UART outputs directly to
95 FT2232x inputs without any buffers.
96
97 Controlling PWON and RESET
98 ==========================
99
100 FT2232x RTS and DTR outputs are normally CMOS high (RS-232 inactive) when no
101 one is poking at them, but the standard Linux kernel ftdi_sio driver (following
102 POSIX stipulations, apparently) unconditionally makes them both CMOS low
103 (RS-232 active) when the ttyUSBx device is opened. If you look in our
104 freecalypso-hwlab Hg repository, you will find a patch to this driver (a quirk
105 conditionalized on a custom USB VID:PID) that suppresses this automatic
106 assertion of RTS & DTR on ttyUSBx device open, allowing userspace applications
107 to control them explicitly with TIOCMBIS and TIOCMBIC ioctls.
108
109 Our upcoming Caramel2+DUART28 solution will include an optional (one may connect
110 the needed jumper wires or leave them unconnected) provision for controlling
111 the Calypso+Iota chipset's PWON and RESET with otherwise unused FT2232 Channel B
112 RTS & DTR outputs. The arrangement we have implemented is that when ChanB RTS
113 is asserted (CMOS low, TIOCMBIS), Calypso PWON is triggered, and when ChanB DTR
114 is asserted, Calypso RESET is triggered. We recommend that others follow the
115 same convention.
116
117 PWON wiring
118 -----------
119
120 The Calypso+Iota chipset's (Iota really) PWON input is internally pulled up to
121 raw VBAT, thus it must not be connected directly to any ordinary 3.3V or 2.8V
122 logic - instead it needs to be driven with an OC or OD buffer. If it is to be
123 controlled with ChanB RTS (FT2232x BDBUS2 output), the ideal circuit is a simple
124 non-inverting OD buffer such as Nexperia 74LVC1G07; the OD buffer IC's Vdd
125 supply should be connected to the FT2232x chip's 3.3V I/O supply rail.
126
127 RESET wiring
128 ------------
129
130 The RESET input is different between Huawei GTM900 and FC Tango modules. On FC
131 Tango it is raw Iota nTESTRESET and thus needs to be driven in the same way as
132 PWON described above, but GTM900 internally incorporates the JTAG reset circuit
133 depicted on TI's Leonardo schematics, and the RESET signal they bring out is
134 what we (FreeCalypso) call XDS_RESET - see the Calypso-test-reset article. It
135 is acceptable to drive XDS_RESET with an OC/OD driver just like PWON or raw
136 nTESTRESET, but this OC/OD driver becomes optional with XDS_RESET - thanks to
137 the transistor circuit inside the GTM900 module, it is perfectly acceptable to
138 wire FT2232x BDBUS4 output (ChanB DTR) directly to GTM900 RST input, and it will
139 work per our convention, triggering a reset when ChanB DTR is asserted.
140
141 The XDS_RESET transistor circuit inside GTM900 does have one unpleasant side
142 effect though: on modules like FC Tango that bring out raw nTESTRESET, that
143 reset includes a built-in Switch-ON function, and PWON effectively becomes
144 optional - one can fully control the module using only RESET and soft poweroff
145 - but the same does NOT hold on GTM900. XDS_RESET may or may not work (no
146 guarantees) when the Calypso+Iota chipset is in VRPC switched-off state, thus
147 one must do a switch-on with PWON first, and then drive a reset if necessary.
148 And no, driving XDS_RESET with an OC/OD buffer won't do anything to eliminate
149 this unpleasant side effect - you just have to live with it for as long as you
150 use GTM900 modules and not FC Tango.