FreeCalypso > hg > freecalypso-docs

comparison Calypso-test-reset @ 15:38cc5795d79c

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Calypso-test-reset article written
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 26 May 2019 10:45:04 +0000
parents
children 396d44c543e3
comparison
equal deleted inserted replaced
14:f5ddeacbe744 15:38cc5795d79c
1 Reset logic and on/off states in the Calypso+Iota chipset
2 =========================================================
3
4 Our beloved Calypso+Iota chipset provides a special reset signal (called
5 nTESTRESET on Leonardo schematics) that is just for testing, development and
6 debugging, not used at all in the normal life cycle of a phone handset or
7 modem. This special test reset is triggered when you press the RESET button on
8 a TI/FreeCalypso development board (D-Sample or FCDEV3B), and it can also be
9 triggered slightly indirectly through the reset pin on the TI-style JTAG
10 connector. The way this reset works is very quirky and requires a lot of
11 explanation, but before one can properly understand this test reset, we first
12 need to look at the "regular" power-on reset, switch-on and switch-off logic
13 that works in the absence of nTESTRESET.
14
15 Before looking at resets and switch-on and switch-off sequences, we first need
16 to understand the power domains that are involved. There are two major power
17 domains of interest: there is the main power domain that is physically powered
18 off when the mobile device is not in the switched-on state, and there is the
19 RTC power domain that is powered at all times whenever the battery is physically
20 present, or perhaps even from a separate backup battery (a tiny coin cell) that
21 provides RTC power when the main battery is removed. The always-on RTC power
22 domain allows the real time clock to maintain the time of day while the mobile
23 is otherwise off (hence the name), and it also provides power to the logic that
24 allows the rest of the mobile (the main power domain) to be powered on,
25 initialized, booted, run and eventually switched off again in an orderly manner.
26
27 All reset and on/off logic in our chipset happens in the VRPC (Voltage Reference
28 and Power Control) block in the Iota chip; all of Calypso and the rest of Iota
29 are fully subservient to this VRPC block. It is crucial to understand the
30 difference between powering on and off vs. switching on and off: in the
31 terminology that is established in TI's chip datasheets and application notes,
32 powering on means physically providing battery power to the chipset (inserting
33 the battery into a phone that had it removed, or connecting a VBAT power supply
34 to the orange power input connector on one of our development boards), and
35 powering off means physically removing all battery power, i.e., yanking the
36 battery out of a phone or disconnecting the power supply from the development
37 board. In board designs with a backup battery or a provision for one, it is
38 even more complicated: a power-on happens when either the main battery or a
39 backup battery becomes present, and a power-off happens when both batteries are
40 removed, leaving the Iota chipset without any energy source whatsoever. In
41 contrast, the actions of a user turning her phone on and off are called
42 switch-on and switch-off, respectively.
43
44 The RTC power domain is powered on and receives its power-on reset (POR) on a
45 power-on event and loses power only on a full power-off (complete loss of all
46 battery power), whereas the main power domain is powered on and lifted out of
47 reset only on a switch-on, and powered back down and held in reset on a
48 switch-off. The Calypso chip receives two reset signals from the Iota (meaning
49 that each signal is an output from the Iota and an input to the Calypso):
50 nRESPWON and ON_nOFF. The nRESPWON signal is asserted (active low) only on a
51 hardware power-on (and also on nTESTRESET as will be explained in due course)
52 and stays high (inactive) at all other times, whereas ON_nOFF is driven high on
53 switch-on and low on switch-off. When the ON_nOFF signal is driven low by the
54 Iota ABB in the switched-off state, all main (non-RTC) logic in the Calypso is
55 held in reset, and in any case that logic cannot function as the physical power
56 to it (coming from LDO regulators in the Iota) will typically be turned off.
57 When the Iota ABB drives ON_nOFF high on switch-on, it does so after the LDO
58 regulators for the main power domain have been turned on and have had enough
59 time to stabilize; in the Calypso chip the transition of ON_nOFF from low to
60 high causes the ARM7 core to boot.
61
62 A true power-on reset happens only when all battery power is removed and
63 reconnected: in simple designs without a backup battery one would need to
64 remove the main battery or the power supply providing VBAT and also disconnect
65 anything that may be feeding power into the system through pull-up resistors;
66 in more complex designs that feature a backup battery, both the main battery
67 and the backup battery would need to be removed and reconnected in order to
68 trigger a POR. Such a complete POR would reset the RTC power domain, and on
69 exit from the POR the VRPC block will be in the switched-off state, with
70 everything except the RTC powered off and waiting for the user to press the
71 PWON button.
72
73 The green LED on the FCDEV3B indicates the state of the ON_nOFF signal, and
74 thus allows you to see if the VRPC block is switched on (LED on) or switched
75 off (LED off). The actual VRPC state machine in the Iota chip is a little more
76 complicated and has 5 states, not just two (the states are NOBAT, BACKUP, OFF,
77 ACTIVE and SLEEP), but I am simplifying here - for the complete details, please
78 see the VRPC description in Iota datasheet TWL3025_SWRS021.pdf, section 4.10
79 starting on page 40. The transition from OFF to ACTIVE (switch-on event)
80 happens whenever the PWON button is pressed or charging voltage is applied (on
81 hardware that has charging circuits), whereas commanding a switch-off (going
82 back to OFF) requires having Calypso ARM7 firmware establish communication with
83 the Iota ABB over SPI and send a DEVOFF command. If the Calypso firmware
84 requests a switch-off when the PWON button is held down (jumper on FCDEV3B) or
85 when a charging power source is present, the Iota VRPC goes through a switch-off
86 immediately followed by a switch-on, effecting a very deep kind of reboot.
87
88 nTESTRESET enters the picture
89 =============================
90
91 So where does nTESTRESET fit in the just-described architecture of on/off
92 switching and resets? Contrary to what one might naively think, it is NOT an
93 externally-triggerable way to simulate a POR, nor is it simply ANDed or ORed
94 together with some other internal reset signal. Instead as you can see in
95 Figure 4-8 on page 43 of the TWL3025_SWRS021.pdf datasheet, it is its own
96 separate and very special path through the VRPC state machine that is never
97 exercised at all in normal product operation.
98
99 When you press the RESET button or trigger a reset through JTAG connector pin 2
100 (let's call it XDS_RESET), the VRPC state machine will unconditionally leave
101 whatever state it was in and will be forced into this special nTESTRESET state
102 that does not occur at any other time. For as long as nTESTRESET is held low,
103 both reset signals to the Calypso (nRESPWON and ON_nOFF) will be held low as
104 well, putting the Calypso into a POR-like superdeep reset, but meanwhile the
105 LDO regulators are fully turned on, not off! While nTESTRESET is held low, the
106 green LED on the FCDEV3B will be off (ON_nOFF is low), but the regulators are
107 on, as can be seen on JTAG connector pin 5 where the V-IO rail is brough out.
108 This combination of ON_nOFF low (green LED off) but regulators on happens only
109 in this special nTESTRESET-held-low state and not at any other time.
110
111 When the RESET button and XDS_RESET are both released, causing nTESTRESET to go
112 back to high, the VRPC state machine goes from the special nTESTRESET state to
113 the ACTIVE (switched-on) state via a special direct transition that bypasses
114 the normal checks. Calypso reset inputs nRESPWON and ON_nOFF go from low to
115 high at the same time (this is the only time when they do it like this), and
116 the ARM7 core boots.
117
118 Thus the test reset triggered via nTESTRESET is not a simple POR-like reset,
119 instead it is a very special "deep reset, then unconditional power-on and boot"
120 kind of operation. As a practical matter, it does its intended job of giving
121 developers an unconditional and unstoppable way to take control of the chipset
122 when the ARM7 processor and its code execution are in a runaway state: in the
123 Calypso+Iota on/off architecture, the most "kosher" way to cleanly reset the
124 system would be a switch-off followed by a switch-on, but a normal switch-off
125 is a quite complex operation that has to be performed by ARM7 firmware, and it
126 is thus unavailable when the processor executes something other than perfectly
127 good firmware code with clean soft-power-off functionality. The test reset
128 mechanism provides a solution, although it is a solution that may be quite
129 difficult to understand at first.
130
131 It is also important to note that nTESTRESET acts the same way and puts the
132 chipset into the exact same state regardless of *all* prior state, as in not
133 only prior sw state, but also prior hw state: in particular, it works exactly
134 the same way whether the chipset was switched on or switched off prior to
135 nTESTRESET assertion. If the system was previously switched on, running some
136 code that hung or become uncontrollable, nTESTRESET can be thought of as acting
137 mostly like a typical processor reset that most software developers are used to,
138 but if the system was previously switched off, nTESTRESET acts like a different
139 kind of "turn on" command, producing a switch-on that is distinguishable from
140 all other switch-on causes like PWON and charger-plug.
141
142 Lack of debouncing
143 ==================
144
145 It is important to note that there is no debouncing circuit for nTESTRESET
146 inside the Iota chip, like there is for the regular PWON button. Thus shorting
147 nTESTRESET to GND directly with a finger-actuated pushbutton switch is not
148 particularly good, although TI's Leonardo schematics depict just such an
149 arrangement, and it works OK on the FCDEV3B in practice.
150
151 The entity that drives nTESTRESET to the Calypso+Iota system takes full
152 responsibility for ensuring proper timing. The reset which is propagated from
153 nTESTRESET to nRESPWON and ON_nOFF needs to have a certain duration in order to
154 reset all logic properly, and there is nothing in the chipset itself to assure
155 such, unlike what happens on normal switch-on sequences - instead it is the
156 responsibility of the nTESTRESET driving source. The exact timing requirements
157 are not stated anywhere (at least none that we could find), but if you are
158 driving nTESTRESET from a programmatic source (presumably via the XDS_RESET
159 signal path described below), I would give it a 50 ms pulse.
160
161 When nTESTRESET is shorted to GND with a finger-actuated pushbutton switch, one
162 needs to watch out for contact bounce. If the dry contact switch does a lot of
163 make-break bounce, that make-break noise will translate directly into Calypso
164 and Iota resets being asserted and negated just as rapidly, which is certainly
165 not clean. The final release from reset is the most important part though: if
166 the system is put through a bunch of erratic resets as a result of contact
167 bounce on the initial RESET button press, there should be no problem if there
168 is a long solid reset at the end, with a clean release from it. But if the
169 release from reset is also accompanied by contact bounce with make-break events
170 on the order of microseconds, then the chipset may enter garbage state by way
171 of an improperly timed reset. The nTESTRESET signal was clearly designed to be
172 driven by development systems that can produce controlled timing, not by
173 bounce-prone electromechanical switches driven by bounce-prone human fingers.
174
175 nTESTRESET vs. XDS_RESET
176 ========================
177
178 In its native form the internal nTESTRESET signal is pulled up to a non-logic
179 voltage rail (specifically UPR, which normally follows VBAT in the absence of
180 backup batteries), and it can be shorted or pulled to GND either by pushbutton
181 switches (aside from the contact bounce problem noted above) or by OC/OD
182 drivers. It cannot, however, be driven by any kind of external push-pull
183 driver, and more generally it cannot be connected to any circuit that operates
184 on standard logic voltages like 3.3 V - the VBAT rail will typically be in the
185 3.6 to 4.2 V range, which is too high for external 3.3 V logic.
186
187 But TI Back In The Day had a need to drive this test reset from their XDS510
188 and XDS560 "emulator" pods, and the only reset signal those pods put out is the
189 one that was originally intended for JTAG TRST (which does not exist in the
190 Calypso+Iota chipset), driven with a push-pull driver. TI's solution was to
191 insert a clever transistor circuit between JTAG connector pin 2 (the pin that
192 was originally intended to be TRST) and the internal nTESTRESET signal; this
193 circuit is depicted on the available Leonardo schematics, it has been replicated
194 on our FCDEV3B, and we have every reason to believe that it is the same on TI's
195 D-Sample board as well. The effect of this circuit is that whenever the
196 external XDS_RESET signal is driven low and the internal V-IO rail has power
197 (see below), the internal nTESTRESET signal is driven low (asserted), and
198 whenever the external XDS_RESET signal is either driven high or left alone, the
199 internal nTESTRESET signal is left alone, high from the pull-up to UPR - but
200 the nTESTRESET and XDS_RESET electrical nets are never exposed directly to each
201 other's voltages.
202
203 This clever solution does however have one side effect which is visible to
204 developers working with these boards: the reset signal isolation circuit can
205 only propagate an asserted low from XDS_RESET to nTESTRESET when the V-IO rail
206 has power, i.e., when Iota regulators are turned on - and in the normal
207 switched-off state these regulators are turned off. Thus the operator needs to
208 first cause a switch-on or at least a regulator turn-on by pressing either the
209 PWON button or the RESET button, and once V-IO is on, the external host driving
210 the XDS_RESET signal via the JTAG connector can take over.
211
212 Another unexpected quirk is that XDS_RESET can still sometimes work even though
213 the Iota regulators are off (VRPC in the switched-off state) if some leakage
214 power is being fed into the V-IO rail from UART or JTAG lines through pull-up
215 resistors - but this behaviour should be considered an unfortunate design
216 blemish, not something to be relied on.
217
218 Test reset, then switch-off, then switch-on quirk
219 =================================================
220
221 If you use any version of FreeCalypso host tools earlier than the upcoming
222 fc-host-tools-r11 release with an FCDEV3B, you might have noticed a really odd
223 quirk: if you make an fc-loadtool entry via the RESET button instead of PWON,
224 then exit your loadtool session cleanly, such that the green LED goes out, the
225 board ends up in a weird state - if you then do a subsequent switch-on via PWON,
226 something goes wrong (fc-loadtool entry doesn't work, regular fw also hangs
227 instead of producing rvinterf output) - it seems as though if you have done a
228 RESET once, only another RESET works from then on, and PWON stops working
229 correctly. Yet if you press the RESET button without fc-loadtool and let the
230 regular firmware boot from this nTESTRESET switch-on, and then execute a
231 switch-off through the firmware (AT@POFF, fc-shell poweroff, or press, hold and
232 release the PWON button) the board is powered off in a clean state - subsequent
233 PWON works just fine. What in the world is going on?
234
235 The secret magic was discovered by carefully studying the TCS211 firmware code
236 we've inherited from TI. It turns out that our Iota chip has at least one
237 secret undocumented register (or perhaps many more, who knows) that is not
238 documented in the TWL3025_SWRS021.pdf datasheet, and any Calypso programs (full
239 firmwares or standalone programs like our loadagent) that execute a Iota
240 poweroff (really switch-off) operation need to make a special write to this
241 magic register in order to avoid trouble in the test reset, then switch-off,
242 then switch-on sequence.
243
244 We are calling this undocumented Iota register VRPCAUX (its official name is
245 unknown, but there is a seemingly-corresponding register in TI's newer Syren
246 ABB chip which the firmware calls VRPCAUX, and the name logically fits in terms
247 of the function), and it is accessed via undocumented register page 2.
248 Officially both Iota and Syren ABB chips only have register pages 0 and 1, but
249 it turns out that both chips also have an undocumented page 2 - and in order to
250 access this secret page 2, one first needs to issue a special (also secret)
251 unlock command through yet other registers - whew!
252
253 So just *why* do we need to mess around with secret undocumented Iota registers
254 from our production code? From what we can tell, this VRPCAUX register lives
255 in the VRPC block in the RTC power domain, and it preserves its state when the
256 rest of the system is powered down in the switched-off state. Apparently this
257 register controls some aspects of the switch-on process, and when an nTESTRESET
258 reset-and-boot sequence is performed, this VRPCAUX register is loaded with a
259 different configuration than on normal POR. It appears that the "normal" value
260 of VRPCAUX in the absence of test reset operations is 0x007 (bit meaning unknown
261 of course when we are dealing with secret undocumented stuff), and this value
262 is needed for switch-on and possibly other things (sleep entry and exit, ABB
263 interrupts, who knows) to work correctly. But if we boot via nTESTRESET and
264 read the secret register, we see 0x2E7 instead - and if we do a normal DEVOFF
265 command without changing it to 0x007 first, we get into the broken state where
266 PWON switch-ons don't work. (It is very reassuring though that another
267 nTESTRESET always works no matter what - so it looks like this debug reset is
268 truly irrespective of all prior hw state.)
269
270 TI's TCS211 firmware has a bit of magic in its boot code path in the ABB_on()
271 function in the chipsetsw/drivers/drv_core/abb/abb.c module, and it has this
272 attention-drawing comment:
273
274 // Restore the ABB checks and debouncing if start on TESTRESETZ
275
276 The code following this comment goes through the gymnastics of enabling access
277 to register page 2, then writing 0x007 into the register which we've named
278 VRPCAUX. (That's what it does for Iota; for Syren it also writes a few other
279 registers also in that same undocumented page 2.) Reproducing these steps in
280 our target-utils code (loadagent and friends) has resulted in the problem
281 behaviour going away: now we can enter fc-loadtool via the RESET button, then
282 exit loadtool (loadagent poweroff command executed on the target), and the
283 board is powered off cleanly, with both PWON and RESET working for subsequent
284 switch-ons. Whew!