WO2021092718A1

WO2021092718A1 - Universal integrated circuit card (uicc) hardware failure recovery

Info

Publication number: WO2021092718A1
Application number: PCT/CN2019/117022
Authority: WO
Inventors: Meng Liu; Jian Li; Wei He; Rajendra Prasad NELUROUTH; Venkata Durga Vinod CHIKKALA
Original assignee: Qualcomm Incorporated
Priority date: 2019-11-11
Filing date: 2019-11-11
Publication date: 2021-05-20

Abstract

A method to recover a subsystem in a device from hardware failure includes recording set register values to a register upon power up of the device, in order to configure a subsystem controller. The method determines that a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem. The method further includes reading temporary register values. The method then determines whether to initialize the subsystem controller based on whether a mismatch occurs between the temporary register values and the set register values.

Description

UNIVERSAL INTEGRATED CIRCUIT CARD (UICC) HARDWARE FAILURE RECOVERY

TECHNICAL FIELD

The present disclosure generally relates to methods and systems for accessing network services on a wireless device. More specifically, the present disclosure relates to recovering a subsystem from hardware failure.

BACKGROUND

Some designs of mobile communications/wireless devices (e.g., smart phones, tablet computers, and laptop computers) include a single universal integrated circuit card (UICC) , multiple universal integrated circuit cards, or multiple subscriber identity module (SIM) cards. The cards store user identity information for multiple subscriptions that enable users to access multiple separate mobile telephony networks. Some of the UICCs (e.g., embedded UICCs (eUICCs) ) are capable of supporting remote provisioning of network subscription information. A UICC may be removable or implemented within memory of mobile communications devices.

The information stored in a UICC may enable mobile communications devices to communicate with a variety of different types of mobile telephony networks. Examples of mobile telephony networks include third generation (3G) , fourth generation (4G) , long term evolution (LTE) , fifth generation (5G) , time division multiple access (TDMA) , code division multiple access (CDMA) , CDMA 2000, wideband CDMA (WCDMA) , global system for mobile communications (GSM) , single-carrier radio transmission technology (1xRTT) , and universal mobile telecommunications systems (UMTS) . Each subscription enabled by a UICC or SIM may utilize a particular radio access technology (RAT) to communicate with its respective network.

SUMMARY

A method to recover a subsystem in a device from hardware failure includes recording set register values to a register upon power up of the device, in order to configure a subsystem controller. The method determines that a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem. The method further includes reading temporary register values. Furthermore, the method includes determining whether to initialize the subsystem controller based on whether a mismatch occurs between the temporary register values and the set register values.

Another aspect of the present disclosure is directed to an apparatus for recovering a subsystem in a device from hardware failure. The apparatus includes a memory, a communication interface coupled to the subsystem, and one or more processors coupled to the memory and the communication interface of the subsystem. The processor (s) is configured to record set register values to a register upon power up of the device, in order to configure a subsystem controller. The processor (s) is further configured to determine that a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem. The processor (s) is further configured to read temporary register values. The processor (s) is also configured to determine whether to initialize the subsystem controller based on whether a mismatch occurs between the temporary register values and the set register values.

Another aspect of the present disclosure is directed to an apparatus for recovering a subsystem in a device from hardware failure. The apparatus includes means for recording set register values to a register upon power up of the device, in order to configure a subsystem controller. The apparatus also includes means for determining that a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem. The apparatus further includes means for reading temporary register values. Furthermore, the apparatus includes means for determining whether to initialize the subsystem controller based on whether a mismatch occurs between the temporary register values and the set register values.

In another aspect of the present disclosure, a non-transitory computer-readable medium records program code. The program code is for recovering a subsystem in a device from hardware failure. The program code is executed by a processor and includes program code to record set register values to a register upon power up of the device, in order to configure a subsystem controller. The program code also includes program code to determine that a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem. The program code further includes program code to read temporary register values. The program code still further includes program code to determine whether to initialize the subsystem controller based on a whether a mismatch occurs between the temporary register values and the set register values.

This has outlined, rather broadly, the features and technical advantages of the present disclosure in order that the detailed description that follows may be better understood. Additional features and advantages of the present disclosure will be described below. It should be appreciated by those skilled in the art that this present disclosure may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the teachings of the present disclosure as set forth in the appended claims. The novel features, which are believed to be characteristic of the present disclosure, both as to its organization and method of operation, together with further objects and advantages, will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, reference is now made to the following description taken in conjunction with the accompanying drawings.

FIGURE 1 shows a wireless device communicating with a wireless communications system.

FIGURE 2 shows a block diagram of the wireless device in FIGURE 1, according to an aspect of the present disclosure.

FIGURE 3 is a process flow diagram of a method of recovering a subsystem from hardware failure, according to aspects of the present disclosure.

FIGURE 4 is a process flow diagram of another method of recovering a subsystem from hardware failure, according to aspects of the present disclosure.

FIGURE 5 is a component block diagram of a wireless device suitable for implementing the method of recovering a subsystem from hardware failure.

FIGURE 6 is a block diagram showing an exemplary wireless communications system in which a configuration of the disclosure may be advantageously employed.

DETAILED DESCRIPTION

The detailed description set forth below, in connection with the appended drawings, is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts. As described herein, the use of the term “and/or” is intended to represent an “inclusive OR” , and the use of the term “or” is intended to represent an “exclusive OR” .

The terms “subscriber identification module, ” “SIM, ” “universal subscriber identity module, ” “USIM, ” “user identity module, ” “UIM, ” “removable user identity module, ” and “RUIM” are used herein to mean a memory that may be an integrated circuit or embedded into a removable card, which stores an international mobile subscriber identity (IMSI) , related key, and/or other information used to identify and/or authenticate a wireless device on a network. In some networks (e.g., GSM networks) , SIMs may store network specific information used to authenticate and identify subscribers on the network, the most important of which are the integrated circuit card identifier (ICCID) , international mobile subscriber identity (IMSI) , authentication key (Ki) , and local area identity (LAI) . The SIM may also store other carrier specific data, such as short message service center (SMSC) numbers, service provider names (SPNs) , service dialing numbers (SDNs) , and value added service (VAS) applications. In various aspects, a USIM and a RUIM may be modules in UMTS and CDMA networks, respectively, which provide equivalent functions to a SIM in a GSM network. However, the terms “SIM, ” “USIM, ” and “RUIM” may be used interchangeably to refer to a general module that is not restricted to a particular standard or technology.

The term “SIM” may also be used as a shorthand reference to a communications network associated with a particular SIM, because the information stored in a SIM enables the wireless device to establish a communications link with a particular network. Thus, the SIM and the communications network, as well as the services and subscriptions supported by that network, correlate to one another.

The terms “universal integrated circuit card, ” “smart card, ” “SIM card, ” and “UICC” are used interchangeably to refer to a memory chip or integrated circuit used to provide a SIM, a USIM, and/or a RUIM, to a wireless device in order to store the described provisioning and/or other data. Various UICCs may have storage capabilities ranging from two to three kilobytes to up to one gigabyte of information.

A universal asynchronous receiver/transmitter (UART) communicates with a wireless device’s SIM card/UIM card/UICC. The UART may be part of a modem or coupled to a modem. For example, the UART is used for transmitting and receiving data through an interface (e.g., a UICC interface) . The UART may be integrated with a UICC controller or the UART supports integration with an internal UICC controller. For example, the UICC controller holds separate logic for each UICC input/output interface assigned to a corresponding UART controller. In some baseband designs, the UICC controller controls pass-through of UICC signals from a universal asynchronous receiver/transmitter data mover (UART_DM) to implementations directed to processor-executable instructions and/or software. The UICC controller should be initialized after every hardware reset. However, a reset associated with implementations directed to processor-executable instructions and/or software may not occur.

UART registers or UICC controller configuration registers include a UICC configuration register (UART_DM_UIM_CFG) and a UICC command register (UART_DM_UIM_CMD) . The UICC configuration register holds different settings for the operation of a UICC controller process assigned to a UICC interface. In one aspect, the UICC configuration register includes sixteen bits, some of which are unchangeable across power cycles. The UICC command register is used to initialize the UICC controller to allow passage of UICC interface signals from the UART to the UICC. The UICC command register is also used to initiate a deactivation sequence by a process command. For example, the UICC controller implements a deactivation sequence on the UICC interface in response to a UICC removal event or a battery-alarm event (battery at low voltage or pulled out) . In some aspects, a serial interface is used to direct signals from a UART controller to the UICC during normal operation. When a deactivation event occurs, the UICC controller overrides this interface to execute the deactivation sequence.

The UICC command register associated with the UICC controller may be linked with the UART_DM. In some implementations, there are restrictions on timing of write access to these UART registers. For example, writing to these registers specifies waiting until UIM-WRITE is done (indication by status-bit or interrupt) before attempting an additional write/read on one of the UART registers. The UIM-WRITE prompt of the UICC command can be executed so long as a UICC input/output write is in progress in the UART_DM.

The UICC controller may include an alarm interface with a power management integrated circuit (PMIC) of a chipset. The alarm interface may be used to detect battery alarm events originating in the PMIC in order to determine whether to execute the deactivation sequence. The alarm interface may be used to send out UICC controller messages to the PMIC to signal a request to cut off the power supply to a UICC card.

The UICC controller configuration registers may include different register values that are used to configure the UICC controller. Some of the register values or bits of the UICC controller configuration registers are settings specific to a particular hardware register or design and are unchangeable across power cycles. These settings can, however, be customized by a user or service provider. After a reset or power up of the device, some of the register values or bits of the UICC controller configuration registers revert to their default values.

Some of the settings include a battery alarm trigger enable value, a UICC card events enable value, and a UICC present polarity value. The battery alarm trigger enable value enables triggering of the deactivation sequence when a battery alarm is detected. For example, the battery alarm may indicate insufficient battery charge. This value may be set (as a default) to enable triggering and cleared (as a default) to disable triggering.

The UICC present polarity value determines how to interpret a UICC signal that represents a presence or absence of a UICC. Setting the UICC present polarity value to “1” means that a UICC card present in a UICC slot returns a value of “1” and an absent UICC returns a value of “0. ” However, setting the UICC present polarity value to “0” means that a UICC card present in the UICC slot returns a value “0” and an absent UICC in the UICC slot returns a value of “1. ” These settings can be selected based on the preference of a user or service provider.

When the UICC events enable is cleared, the UICC controller does not react to any UICC event (insertion/removal) . However, when the UICC events enable is set, the UICC controller reacts to UICC events and is considered active. In one aspect, the bit corresponding to the UICC events enable value is set only after or during a setting of the bit corresponding to the UICC present polarity value. Setting the UICC events enable value prevents the UICC controller from interpreting card-events incorrectly due to a wrong polarity configuration. For example, a reset value of the polarity might not match an actual value.

We note that the UART may also feature other reset implementations directed to processor-executable instructions and/or software that include reset commands via other registers (UART_DM_CR registers) that reset data channels only and not registers and configuration. The other registers directed to processor-executable instructions and/or software do not support features supported by the UART registers. For example, these features include the battery alarm trigger enable value, the UICC card events enable value, and the UICC present polarity value. However, these features are expected to be unchanged across a power cycle or project life cycle. Accordingly, the bits corresponding to a status of these features can be monitored in accordance with the reset implementations to determine whether the UICC controller was reset accidently.

After hardware reset, the UART is not capable of any data transfer. Data channels are disabled by default and characters cannot be received through a receive channel nor transmitted through a transmit channel. For example, after the hardware reset, the UICC controller blocks the pass-through of the UICC signals from the UART to the UICC card. The UART and the UICC controller are initialized after every hardware reset. In some aspects, the hardware reset may be a partial hardware reset.

Some UICC controller hardware of some chipsets has been found to reset (hardware reset) by accident during standby or during an electro-static discharge (ESD) test. When this accidental or erroneous hardware reset occurs, process implementations directed to processor-executable instructions and/or software are unaware of the accidental hardware reset.

The only indication of the accidental reset, with respect to the process implementation, is that “hot-swap” status for the UICC has changed to “removed. ” This follows because a UICC controller hardware reset corresponds to a “hot-swap” status change. As a result of the false indication that the UICC is “removed, ” the UICC is lost or cannot be identified with respect to the implementations directed to processor-executable instructions and/or software. The UART may also feature other reset implementations directed to processor-executable instructions and/or software that include reset commands via other registers (e.g., a UART command register) that only reset data channels and not registers and configurations. The UART command register is used to issue specific commands to a UART subsystem. However, aspects of the present disclosure are directed to the hardware reset.

Because the current status of the UICC is “removed, ” there is no need to initialize the UICC controller for a UICC that is removed. Thus, the failure associated with the erroneous hardware reset cannot be resolved unless the overall system is rebooted. For example, because the UICC controller cannot be re-initialized, “hot-swap” interrupt cannot be achieved. As a result, recovery after the erroneous hardware reset persists until an overall system reboot.

Aspects of the present disclosure are directed to a method of recovering a subsystem (e.g., a UICC) in a wireless device from hardware failure without an overall system reboot. In one aspect, a processor (e.g., the baseband processor) of the wireless device causes set register values or register value settings, used to configure a controller of the subsystem, to be recorded in a configuration register after the wireless device is powered up. The processor determines that a hardware reset associated with the UICC indicates a change in an insertion status of the subsystem. The change in the insertion status corresponds to a “hot-swap” status change, where the UICC is lost/removed or appears to be lost/removed. For example, while the UICC may operate normally throughout a power cycle, in some instances, the UICC is lost as a result of a hardware reset.

The processor reads or causes temporary register values to be read. These temporary register values may be set register values or portions of the set register values. The temporary register values may be based on the set register values. For example, the temporary register values and the set register values may have unchangeable bits that may be slightly different from each other depending on customer or user preference. For example, setting the UICC present polarity value to “1” means that a UICC card present in a UICC slot returns a value of “1” and an absent UICC returns a value of “0. ” However, setting the UICC present polarity value to “0” means that a UICC card present in the UICC slot returns a value “0” and an absent UICC in the UICC slot returns a value of “1. ”

The processor determines whether to initialize the subsystem controller based on a determination of whether there is a mismatch between the temporary register values and the set register values. For example, determining whether there is a mismatch between the temporary register values and the set register values includes determining whether there is a mismatch between the unchangeable bits of the temporary register values and the unchangeable bits of the set register values. In one aspect, the subsystem controller is initialized when there is a mismatch between the temporary register values and the set register values.

FIGURE 1 shows a wireless device 110 that includes the described universal integrated circuit card where a controller of the universal integrated circuit card is recovered from a hardware failure by the method described. The wireless device 110 communicates with a wireless communications system 120. The wireless device 110 includes a multi-band (e.g., dual-band) concurrent millimeter wave (mmW) transceiver. The wireless communications system 120 may be a 5G system, a long term evolution (LTE) system, a code division multiple access (CDMA) system, a global system for mobile communications (GSM) system, a wireless local area network (WLAN) system, millimeter wave (mmW) technology, or some other wireless system. A CDMA system may implement wideband CDMA (WCDMA) , time division synchronous CDMA (TD-SCDMA) , CDMA2000, or some other version of CDMA. In a millimeter wave (mmW) system, multiple antennas are used for beamforming (e.g., in the range of 30 GHz, 60 GHz, etc. ) . For simplicity, FIGURE 1 shows the wireless communications system 120 including two

base stations

130 and 132 and one system controller 140. In general, a wireless system may include any number of base stations and any number of network entities.

A wireless device 110 may be referred to as a mobile equipment (ME) , a user equipment (UE) , a mobile station, a terminal, an access terminal, a subscriber unit, a station, etc. The wireless device 110 may also be a cellular phone, a smartphone, a tablet, a wireless modem, a personal digital assistant (PDA) , a handheld device, a laptop computer, a Smartbook, a netbook, a cordless phone, a wireless local loop (WLL) station, a Bluetooth device, etc. The wireless device 110 may be capable of communicating with the wireless communications system 120. The wireless device 110 may also be capable of receiving signals from broadcast stations (e.g., a broadcast station 134) , signals from satellites (e.g., a satellite 150) in one or more global navigation satellite systems (GNSS) , etc. The wireless device 110 may support one or more radio technologies for wireless communications such as 5G, LTE, CDMA2000, WCDMA, TD-SCDMA, GSM, 802.11, etc.

The wireless device 110 may support carrier aggregation, which is operation on multiple carriers. Carrier aggregation may also be referred to as multi-carrier operation. According to an aspect of the present disclosure, the wireless device 110 may be able to operate in low-band from 698 to 960 megahertz (MHz) , mid-band from 1475 to 2170 MHz, and/or high-band from 2300 to 2690 MHz, ultra-high band from 3400 to 3800 MHz, and long-term evolution (LTE) in LTE unlicensed bands (LTE-U/LAA) from 5150 MHz to 5950 MHz. Low-band, mid-band, high-band, ultra-high band, and LTE-U refer to five groups of bands (or band groups) , with each band group including a number of frequency bands (or simply, “bands” ) . For example, in some systems each band may cover up to 200 MHz and may include one or more carriers. For example, each carrier may cover up to 40 MHz in LTE. Of course, the range for each of the bands is merely exemplary and not limiting, and other frequency ranges may be used. LTE Release 11 supports 35 bands, which are referred to as LTE/UMTS bands and are listed in 3GPP TS 36.101. The wireless device 110 may be configured with up to five carriers in one or two bands in LTE Release 11.

Some carrier aggregation implementations in the sub 6 GHz include multiple frequency bands in the millimeter wave frequency range, such as frequency bands located near 24 gigahertz (GHz) , 26 GHz, 28 GHz, 37 GHz, 39 GHz, 48 GHz, and 56 to 71 GHz.. For example, these bands may include 24.25-24.45 GHz, 24.75-25.25 GHz, 27.5-28.35 GHz, and 37-40 GHz. In these systems, the carriers may be 50 MHz, 100 MHz, 200 MHz, or 400 MHz and the bands may be up to 2.4 GHz and may include one or more carriers.

FIGURE 2 shows a block diagram of the wireless device 110 in FIGURE 1, according to an aspect of the present disclosure. The wireless device 110 may include a universal integrated circuit card (UICC) interface 202, which may receive an embedded UICC (eUICC) 204 that stores profiles associated with one or more subscriptions from network providers.

A UICC used in various examples may include user account information, an international mobile subscriber identity (IMSI) , a set of SIM application toolkit (SAT) commands, and storage space for phone book contacts. The UICC may further store home identifiers (e.g., a system identification number (SID) /network identification number (NID) pair, a home preferred list of mobile networks (HPLMN) code, etc. ) to indicate the network operator providers for each subscription of the UICC. An integrated circuit card identity (ICCID) SIM serial number may be printed on the UICC for identification. In some aspects, the UICC may be implemented within a portion of memory of the wireless device 110 (e.g., in a memory 214) , and thus need not be a separate or removable circuit, chip, or card.

The wireless device 110 may include at least one controller, such as a general processor 206, which may be coupled to a coder/decoder (CODEC) 208. The CODEC 208 may in turn be coupled to a speaker 210 and a microphone 212. The general processor 206 may also be coupled to the memory 214. The memory 214 may be a non-transitory computer-readable storage medium that stores processor-executable instructions. The memory 214 may store an operating system (OS) , as well as user application software and executable instructions. The memory 214 may also store locally cached profiles for subscriptions supported by the eUICC 204.

The general processor 206 and the memory 214 may each be coupled to at least one baseband processor or baseband modem processor 216. The eUICC 204 in the wireless device 110 may utilize one or more baseband-RF resources. A baseband-RF resource may include the baseband modem processor 216, which may perform baseband/modem functions for communications with and controlling of a radio access technology (RAT) . The baseband-RF resource may include one or more amplifiers and radios, referred to generally as RF resources (e.g., RF resource 218) . In some examples, the baseband-RF resources may share the baseband modem processor 216 (e.g., a single device that performs baseband/modem functions for all RATs on the wireless device 110) . In other examples, each baseband-RF resource may include physically or logically separate baseband processors (e.g., BB1, BB2) .

The RF resource 218 may be a transceiver that performs transmit/receive functions for the eUICC 204 on the wireless device 110. The RF resource 218 may include separate transmit and receive circuitry, or may include a transceiver that combines transmitter and receiver functions. In some examples, the RF resource 218 may include multiple receive circuits. The RF resource 218 may be coupled to a wireless antenna (e.g., a wireless antenna 220) . The RF resource 218 may also be coupled to the baseband modem processor 216.

In some examples, the general processor 206, the memory 214, the baseband modem processor (s) 216, and the RF resource 218 may be included in the wireless device 110 as a system-on-chip 250. In some examples, the eUICC 204 and its corresponding UICC interface 202 may be external to the system-on-chip 250. Further, various input and output devices may be coupled to components on the system-on-chip 250, such as interfaces or controllers. Example user input components suitable for use in the wireless device 110 may include, but are not limited to, a keypad 224, a touchscreen display 226, and the microphone 212.

In some examples, the keypad 224, the touchscreen display 226, the microphone 212, or a combination thereof, may perform the function of receiving a request to initiate an outgoing call or for receiving a person identification number. Interfaces may be provided between the various devices and modules to implement functions in the wireless device 110 to enable communications in the wireless device.

Functioning together, the eUICC 204, the baseband processor BB1, BB2, the RF resource 218, and the wireless antenna 220 may constitute two or more radio access technologies (RATs) . For example, the wireless device 110 may be a communications device that includes a UICC, baseband processor, and RF resource configured to support two different RATs, such as 5G or LTE and GSM. More RATs may be supported on the wireless device 110 by adding more RF resources, and antennae for connecting to additional mobile networks.

In some examples (not shown) , the wireless device 110 may include, among other things, additional UICC or SIM cards, UICC or SIM interfaces, multiple RF resources associated with the additional UICC or SIM cards, and additional antennae for supporting subscriptions communications with additional mobile networks.

The eUICC 204 may support multiple mobile network operator profiles, or subscription profiles. For example, a user may download multiple profiles onto the eUICC 204. Each profile may store static SIM information that is used to support a subscription with one or more mobile telephony networks. Thus, the eUICC 204 may play the role of multiple SIMs, because each SIM supports one profile.

In various examples, the wireless device 110 may be configured to locally cache one or more subscription profiles associated with or stored in the UICC. The profiles may be cached in the memory 214, part of which may be designated memory for the modem.

FIGURE 3 is a process flow diagram of a method 300 to recover a subsystem in a wireless device from hardware failure, according to aspects of the present disclosure. At block 302, the wireless device configured to include a subsystem, such as a UICC, is powered up. At block 304, a processor (e.g., a baseband processor) records set register values that are used to configure a subsystem controller (e.g., UICC controller) . The set register values are stored in memory or in a configuration register. For example, to work with the UICC controller in a UICC mode, UART registers (e.g., UICC controller configuration registers) store set register values from a configuration file.

At block 306, the UICC controller is initialized. The initialization of the UICC controller may occur under normal operating conditions. The set register values are used to initialize the UICC controller. At block 308, the UICC is powered up after initializing the UICC controller. At block 310, the system performs a normal UICC interaction under the normal operating conditions. For example, a normal SIM interaction includes UICC power up procedure and application protocol data unit (APDU) exchange. At block 312, a processor of the wireless device determines that a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem. The change in the insertion status corresponds to a “hot-swap” status change where the UICC is lost/removed or appears to be lost/removed. For example, while the UICC may operate normally throughout a power cycle, in some instances, the UICC is lost as a result of a hardware reset.

At block 314, the processor reads temporary register values. These temporary register values may be the set register values or portions of the set register values that may have been updated by a user or service provider to create the temporary register values. At block 316, it is determined whether there is a mismatch between the temporary register values and the set register values. For example, it is determined whether there is a mismatch between unchangeable bits of the temporary register values and unchangeable bits of the set register values.

When the UICC is lost and the UICC controller did not reset, a delay is applied before checking or monitoring the register for temporary register values. For example, when there is a match between the temporary register values and the set register values, a temporary delay (e.g., a pre-determined delay) is applied to the recovering process, at block 318. After the pre-determined delay, the processor resets a retry count, at block 320. The retry count is reset knowing that the unchangeable register bits are maintained. At block 322, the processor determines whether the subsystem or UICC is absent after resetting the retry count. When it is determined that the subsystem is absent, the recovering process returns to block 314 where the processor reads the temporary register values. Otherwise, when it is determined that the subsystem is present, the recovering process returns to block 310 where a normal subsystem interaction is performed. This follows because the UICC may have been powered up again.

At block 324, the processor determines whether a maximum retry count is exceeded when there is a mismatch between the temporary register values and the set register values. A mismatch indicates a reset of the UICC controller. At block 326, the processor causes the retry count to be adjusted (e.g., increased) when it is determined that the maximum retry count is not exceeded. The process then returns to block 306 where the subsystem or UICC controller is initialized. When it is determined that the maximum retry count is exceeded, this means that the retry cannot fix the hardware issue. Accordingly, the process continues to block 328 where the process stops monitoring the register values (e.g., the temporary register values) when it is determined that the maximum retry count is exceeded.

Aspects of the present disclosure recover a subsystem (e.g., a UICC) in a wireless device from hardware failure without overall system reboot.

FIGURE 4 depicts a simplified flowchart of a method 400 for recovering a subsystem (e.g., a UICC) in a device (e.g., a wireless device) from hardware failure. At block 402, a processor (e.g., a baseband processor) of the wireless device records set register values to configure a subsystem controller to a memory (e.g., register) upon power up of the wireless device. At block 404, the processor determines that a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem. At block 406, the processor reads temporary register values. At block 408, the processor determines whether to initialize the subsystem controller based on a determination of whether there is a mismatch between the temporary register values and the set register values.

According to a further aspect of the present disclosure, an apparatus for recovering a subsystem (e.g., a UICC) in a wireless device from hardware failure is described. The apparatus may include means for recording, means for determining a hardware reset, means for reading temporary register values, and/or means for determining whether to initialize the subsystem controller. The recording means, hardware reset determining means, reading means, and/or subsystem controller initialization determining means may be the baseband modem processor 216, the general processor 206, and/or the memory 214. In another aspect, the aforementioned means may be any module or apparatus configured to perform the functions recited by the aforementioned means.

FIGURE 5 is a component block diagram of a wireless device 500 suitable for implementing the method of recovering a subsystem in the wireless device. Aspects of the present disclosure may be implemented in any of a variety of wireless devices, an example of which (e.g., wireless device 500) is illustrated in FIGURE 5. The wireless device 500 may be similar to the wireless device 110 and may implement the method 300 and the method 400.

The wireless device 500 may include a processor 502 coupled to a touchscreen controller 504 and an internal memory 506. The processor 502 may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory 506 may be volatile or non-volatile memory, and may also be secure and/or encrypted memory, or unsecure and/or unencrypted memory, or any combination thereof. The touchscreen controller 504 and the processor 502 may also be coupled to a touchscreen panel 512, such as a resistive-sensing touchscreen, capacitive-sensing touchscreen, infrared sensing touchscreen, etc. Additionally, the display of the wireless device 500 need not have touch screen capability.

The wireless device 500 may have one or more cellular network transceivers 508 coupled to the processor 502 and to one or more antennas 510 and configured for sending and receiving cellular communications. The one or more transceivers 508 and the one or more antennas 510 may be used with the above-mentioned circuitry to implement the various example methods described. The wireless device 500 may include one or more UICC or SIM cards 516 coupled to the one or more transceivers 508 and/or the processor 502 and may be configured as described above.

The wireless device 500 may also include speakers 514 for providing audio outputs. The wireless device 500 may also include a housing 520, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components discussed herein. The wireless device 500 may include a power source 522 coupled to the processor 502, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the wireless device 500. The wireless device 500 may also include a physical button 524 for receiving user inputs. The wireless device 500 may also include a power button 526 for turning the wireless device 500 on and off.

FIGURE 6 is a block diagram showing an exemplary wireless communications system in which a configuration of the disclosure may be advantageously employed. For purposes of illustration, FIGURE 6 shows three

remote units

620, 630, and 650 and two base stations 640. It will be recognized that wireless communications systems may have many more remote units and base stations.

Remote units

620, 630, and 650 include

IC devices

625A, 625B, and 625C that include the disclosed subsystem or universal integrated circuit card. It will be recognized that other devices may also include the disclosed subsystem, such as the base stations, switching devices, and network equipment. FIGURE 6 shows forward link signals 680 from the base station 640 to the

remote units

620, 630, and 650 and reverse link signals 690 from the

remote units

620, 630, and 650 to base station 640.

In FIGURE 6, remote unit 620 is shown as a mobile telephone, remote unit 630 is shown as a portable computer, and remote unit 650 is shown as a fixed location remote unit in a wireless local loop system. For example, a remote unit may be a mobile phone, a hand-held personal communications systems (PCS) unit, a portable data unit such as a personal digital assistant (PDA) , a GPS enabled device, a navigation device, a set top box, a music player, a video player, an entertainment unit, a fixed location data unit such as a meter reading equipment, or other communications device that stores or retrieves data or computer instructions, or combinations thereof. Although FIGURE 6 illustrates remote units according to the aspects of the disclosure, the disclosure is not limited to these exemplary illustrated units. Aspects of the disclosure may be suitably employed in many devices, which include the subsystem.

For a firmware and/or software implementation, the methodologies may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. A machine-readable medium tangibly embodying instructions may be used in implementing the methodologies described herein. For example, software codes may be stored in a memory and executed by a processor unit. Memory may be implemented within the processor unit or external to the processor unit. As used herein, the term “memory” refers to types of long term, short term, volatile, nonvolatile, or other memory and is not to be limited to a particular type of memory or number of memories, or type of media upon which memory is stored.

If implemented in firmware and/or software, the functions may be stored as one or more instructions or code on a computer-readable medium. Examples include computer-readable media encoded with a data structure and computer-readable media encoded with a computer program. Computer-readable media includes physical computer storage media. A storage medium may be an available medium that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer; disk and disc, as used herein, includes compact disc (CD) , laser disc, optical disc, digital versatile disc (DVD) , floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

In addition to storage on computer-readable medium, instructions and/or data may be provided as signals on transmission media included in a communications apparatus. For example, a communications apparatus may include a standard cell circuit having signals indicative of instructions and data. The instructions and data are configured to cause one or more processors to implement the functions outlined in the claims.

The various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

Although the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the technology of the disclosure as defined by the appended claims. For example, relational terms, such as “above” and “below” are used with respect to a substrate or electronic device. Of course, if the substrate or electronic device is inverted, above becomes below, and vice versa. Additionally, if oriented sideways, above and below may refer to sides of a substrate or electronic device. Moreover, the scope of the present application is not intended to be limited to the particular configurations of the process, machine, manufacture, and composition of matter, means, methods, and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding configurations described herein may be utilized according to the present disclosure. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

Claims

A method to recover a subsystem in a device from hardware failure, comprising:

recording set register values to a register upon power up of the device, in order to configure a subsystem controller;

determining a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem;

reading temporary register values; and

determining whether to initialize the subsystem controller based on whether a mismatch occurs between the temporary register values and the set register values.
The method of claim 1, in which the mismatch comprises a mismatch between unchangeable bits of the temporary register values and unchangeable bits of the set register values.
The method of claim 1, further comprising initializing the subsystem controller when the mismatch occurs.
The method of claim 1, further comprising resetting a retry count after a pre-determined delay when there is no mismatch between the temporary register values and the set register values.
The method of claim 4, further comprising determining whether the subsystem is absent after resetting the retry count.
The method of claim 4, in which reading the temporary register values comprises reading the temporary register values when the subsystem is absent.
The method of claim 4, further comprising performing a normal subsystem interaction when the subsystem is present.
The method of claim 1, further comprising determining whether a maximum retry count is exceeded when the mismatch occurs.
The method of claim 8, further comprising adjusting a retry count based on whether the maximum retry count is exceeded.
The method of claim 9, in which adjusting the retry count comprises increasing the retry count before initializing the subsystem controller when the maximum retry count is not exceeded.
The method of claim 1, in which the subsystem comprises a universal integrated circuit card (UICC) .
An apparatus for recovering a subsystem in a device from hardware failure comprising:

a memory;

a communication interface coupled to the subsystem; and

at least one processor coupled to the memory and the communication interface of the subsystem, the at least one processor configured:

to record set register values to a register upon power up of the device, in order to configure a subsystem controller;

to determine a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem;

to read temporary register values; and

to determine whether to initialize the subsystem controller based on whether a mismatch occurs between the temporary register values and the set register values.
The apparatus of claim 12, in which the mismatch comprises a mismatch between unchangeable bits of the temporary register values and unchangeable bits of the set register values.
The apparatus of claim 12, in which the at least one processor is further configured to initialize the subsystem controller when the mismatch occurs.
The apparatus of claim 12, in which the at least one processor is further configured to reset a retry count after a pre-determined delay when there is no mismatch between the temporary register values and the set register values.
The apparatus of claim 15, in which the at least one processor is further configured to determine whether the subsystem is absent after resetting the retry count.
The apparatus of claim 15, in which the at least one processor is further configured to read the temporary register values when the subsystem is absent.
The apparatus of claim 15, in which the at least one processor is further configured to perform a normal subsystem interaction when the subsystem is present.
The apparatus of claim 12, in which the at least one processor is further configured to determine whether a maximum retry count is exceeded when the mismatch occurs.
The apparatus of claim 19, in which the at least one processor is further configured to adjust a retry count based on whether the maximum retry count is exceeded.
The apparatus of claim 20, in which the at least one processor is further configured to adjust the retry count by increasing the retry count before initializing the subsystem controller when the maximum retry count is not exceeded.
The apparatus of claim 12, in which the subsystem comprises a universal integrated circuit card (UICC) .
An apparatus for recovering a subsystem in a device from hardware failure comprising:

means for recording set register values to a register upon power up of the device, in order to configure a subsystem controller;

means for determining a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem;

means for reading temporary register values; and

means for determining whether to initialize the subsystem controller based on whether a mismatch occurs between the temporary register values and the set register values.
A non-transitory computer-readable medium having program code recorded thereon for recovering a subsystem in a device from hardware failure, the program code executed by a processor and comprising:

program code to record set register values to a register upon power up of the device, in order to configure a subsystem controller;

program code to determine a hardware reset associated with the subsystem indicates a change in an insertion status of the subsystem;

program code to read temporary register values; and

program code to determine whether to initialize the subsystem controller based on whether a mismatch occurs between the temporary register values and the set register values.