文档章节

掉卡问题的分析总结

HouWeiGui
 HouWeiGui
发布于 2017/01/13 11:32
字数 3494
阅读 81
收藏 0

一、mtk平台掉卡:

相关AT:

主动上报:AT+ESIMS

开关飞行模式: AT+EPOF

切换主卡: AT+ES3G=2, 7

卡类型的上报:EUSIM

掉卡后流程异常:

“AT+ECSRA=2,1,0,1,1,0”没有返回,引起mode switch 被pending无法上报最终卡的状态。

共卡座的配置:

\ProjectConfig.mk
配置的就是no:MTK_SIM_HOT_SWAP_COMMON_SLOT = no

属性查看: [ro.mtk_sim_hot_swap_common_slot]: [1]

实例:

可以通过AT来check是否掉卡:

1.modem 上报 ESIMS:0,13表示救卡,
如果recovery救回SIM卡那么会上报ESIMS:1,14
否则掉卡了
2.modem 上报 ESIMS:0,11 拔卡
 

log如下:
11:22:58:400第一次出现问题(command timeout)。
11:23:01:000开始尝试恢复(共做了3次),对SIM卡做power on reset,均是无任何反应。
11:23:33:345开始做最后一次恢复,但SIM卡问题依旧(先是command timeout,然后下power on reset无反应)。

这题目前的结论:
倾向于认为是SIM卡出现的偶发性异常。(SIM卡可正常使用,但偶尔会挂一次,之后又可正常使用)
刚也有提到,SIM卡是一个运行着软体的小系统,
它偶尔也会发生不稳定的情况(比如timeout,返回异常的status word 等等),
若出现上述情况(SIM卡出现异常),会表现得非常偶发,并较难复制。


Type    Index    Time    Local Time    Module    Message    Comment    Time Different
PS    1145008    384951    11:22:58:400    SIM    APDU_tx 0: 80 F2 00 00 00 F2 F2 F2 F2 00 00 00 13 02 12 02        
PS    1145009    384951    11:22:58:400    SIM_DRV    L1sim_Cmd_Layer_MTK(0) P3=0 txSize=5, rxData!=NULL, *rxSize=256
PS    1145010    384951    11:22:58:400    SIM_DRV    [MOD_SIM_DRV] CMD header: 80 f2 0 0 0, txSize:5, rxSize:256
PS    1172528    385266    11:23:00:000    SIM_DRV    [DRV] SIM HISR int: 8

PS    1189889    385492    11:23:01:000    SIM    [SIM_GEN1] file 2, line 68e, fffffffd 4, 0 0 1 3c3c2e3        
PS    1191071    385505    11:23:01:200    SIM    SIM_RESET_ERROR: DCL_USIM_NO_INSERT        
PS    1209930    385708    11:23:02:200    SIM    [SIM_GEN1] file 2, line 68e, fffffffd 4, 0 0 1 3c44d22        
PS    1210870    385721    11:23:02:200    SIM    SIM_RESET_ERROR: DCL_USIM_NO_INSERT        
PS    1225832    385924    11:23:03:200    SIM    [SIM_GEN1] file 2, line 68e, fffffffd 4, 0 0 1 3c4d761        
PS    1226858    385937    11:23:03:200    SIM    SIM_RESET_ERROR: DCL_USIM_NO_INSERT        

PS    1261841    391937    11:23:33:345    SIM    SIM RESET at 1.8V        
PS    1261842    391937    11:23:33:345    SIM    SIM_RESET_ERROR: DCL_USIM_NO_ERROR        
PS    1261844    391937    11:23:33:345    SIM    APDU_tx 0: 00 A4 08 04 02 2F E2 00 F2 F2 F2 F2 00 00 00 00        
PS    1261863    391937    11:23:33:345    SIM    SELECT:GLOBAL_FILES_START => 00 00        
PS    1225832    385924    11:23:03:200    SIM    [SIM_GEN1] file 2, line 68e, fffffffd 4, 0 0 1 3c4d761        
PS    1226858    385937    11:23:03:200    SIM    SIM_RESET_ERROR: DCL_USIM_NO_INSERT

关于mtk平台apdu的解析:
Type    Index    Time    Local Time    Module    Message    Comment    Time Different
PS    1145008    384951    11:22:58:400    SIM    APDU_tx 0: 80 F2 00 00 00 F2 F2 F2 F2 00 00 00 13 02 12 02        
PS    1261844    391937    11:23:33:345    SIM    APDU_tx 0: 00 A4 08 04 02 2F E2 00 F2 F2 F2 F2 00 00 00 00        

1. 打印log时每行都会显示16 byte 内容、APDU_tx表示发给卡的data,但是如果第5 byte后出现了“F2”、则之后都是invalid值(每行都要打印16 byte,不足时用F2区分)。因此,上述两行log真正下发给卡的APDU为
PS    1145008    384951    11:22:58:400    SIM    APDU_tx 0: 80 F2 00 00 00         
PS    1261844    391937    11:23:33:345    SIM    APDU_tx 0: 00 A4 08 04 02 2F E2 00

关于mtk平台的救卡机制介绍:

1、从log看既然已经显示是DCL_USIM_NO_INSERT,也就是未插卡状态,那么这个掉卡的时候是否会触发热插拔机制呢?非要等到每次终端去查卡的状态才会发现掉卡了吗。
=>这里显示DCL_USIM_NO_INSERT可能会误导,它真实的意思是SIM卡检测失败,上层就不会再走SIM卡的init流程,并且报告没检测到卡。但SIM卡还在卡槽里面。所以这里跟热插拔没有关系了。

2、你说每次发reset power on的命令尝试救卡,从log里看到了[L1usim_Reset,4025] retry_2 1的命令,但是未看到设置定时器,也就是说没看到你说的命令超时还未收到sim卡回复的判断依据。另外reset power on的机制除了在救卡的时候会发这个命令,还有其他应用场景吗
=>SIM卡timeout是通过SIM控制器来检测的,并通过相应的interrupt报告给driver(int Status:20)。除了救卡时做power on reset,每次热插拔重新插入SIM后都会以power on reset为起始,并完成后续一系列的SIM init flow。

3、每次在reset命令前后都会看到turn on vsim0 ,turn off vsim0,这两条命令什么意思,是否对救卡有影响
=>所谓reset就是power on reset,意指要对SIM卡做“掉电->上电->reset”的操作,就是对应的“turn on vsim0 ,turn off vsim0”。这是救卡的正常动作。

二、MTK平台检卡失败

贵司此题检卡时没有收到ATR,这种一般都是由于插拔卡时,没有将卡插好或者卡槽松动,导致接触不良引起。
12199, 385, 809, 10:53:34:640 2017/02/25, MOD_SIM_2, , TRACE_STATE, SIM: sim recovery enhancement switch on!
12579, 443, 867, 10:53:35:040 2017/02/25, MOD_SIM_DRV, , TRACE_INFO, [L1usim_Reset,4002] retry 0
12610, 497, 921, 10:53:35:240 2017/02/25, MOD_SIM_DRV, , TRACE_INFO, [L1usim_Reset,4002] retry 1
12639, 551, 975, 10:53:35:440 2017/02/25, MOD_SIM_DRV, , TRACE_INFO, [L1usim_Reset,4025] retry_2 0
12666, 605, 1029, 10:53:35:840 2017/02/25, MOD_SIM_DRV, , TRACE_INFO, [L1usim_Reset,4025] retry_2 1
12774, 606, 1030, 10:53:35:840 2017/02/25, MOD_SIM_DRV, , TRACE_INFO, EINT: 0, 0 0 100 0 0 0
12775, 606, 1030, 10:53:35:840 2017/02/25, MOD_SIM_DRV, , TRACE_INFO, EINT: MD1_SIM1_HOT_PLUG_EINT
12776, 606, 1030, 10:53:35:840 2017/02/25, MOD_SIM_2, , TRACE_INFO, SIM_RESET_ERROR: DCL_USIM_NO_INSERT
17780, 843, 1267, 10:53:37:040 2017/02/25, MOD_SIM_DRV, , TRACE_INFO, [SIM_DRV]:SIM1 ATR= 3B9D94801FC78031E073FE211365D001A47C12C1

开关飞行模式的APlog

Line 25461: 02-25 10:53:30.907415 268 268 D ccci_mdinit(1): set md status:mtk.md1.status=flightmode
Line 25464: 02-25 10:53:30.909925 268 268 D ccci_mdinit(1): set md status:mtk.md1.status=reset
Line 25636: 02-25 10:53:31.306080 268 268 D ccci_mdinit(1): set md status:mtk.md1.status=bootup
Line 25654: 02-25 10:53:31.605415 268 268 D ccci_mdinit(1): set md status:mtk.md1.status=ready

三、转自别人博客的关于APDU的命令:

APDU指令分为command APDU跟response APDU。
ETSI 102.221.描述了command APDU指令的结构。

Code Length Description Grouping
CLA   1     Class of instruction
INS    1     Instruction code
P1     1     Instruction parameter 1
P2     1     Instruction parameter 2
Lc   0 or 1   Number of bytes in the command data field
Data Lc     Command data string
Le 0 or 1    Maximum number of data bytes expected in response of the command

response APDU的结构。
Code Length Description
Data   Lr    Response data string
SW1   1     Status byte 1
SW2   1     Status byte 2
       以下来自ISO7816-5,描述了在UICC卡里所使用的命令以及其相对应的INS(操作码)。USIM卡中各种命令的相关具体格式以及应用请查阅3gpp相关文档。
COMMAND          CLA              INS
Command APDUs
SELECT FILE     '0X' or '4X' or '6X'      'A4'
STATUS          '8X' or 'CX' or 'EX'     'F2'
READ BINARY    '0X' or '4X' or '6X'      'B0'
UPDATE BINARY '0X' or '4X' or '6X'     'D6'
READ RECORD    '0X' or '4X' or '6X'     'B2'
UPDATE RECORD '0X' or '4X' or '6X' 'DC'
SEARCH RECORD '0X' or '4X' or '6X' 'A2'
INCREASE '8X' or 'CX' or 'EX' '32'
RETRIEVE DATA '8X' or 'CX' or 'EX' 'CB'
SET DATA '8X' or 'CX' or 'EX' 'DB'
VERIFY '0X' or '4X' or '6X' '20'
CHANGE PIN '0X' or '4X' or '6X' '24'
DISABLE PIN '0X' or '4X' or '6X' '26'
ENABLE PIN '0X' or '4X' or '6X' '28'
UNBLOCK PIN '0X' or '4X' or '6X' '2C'
DEACTIVATE FILE '0X' or '4X' or '6X' '04'
ACTIVATE FILE '0X' or '4X' or '6X' '44'
AUTHENTICATE '0X' or '4X' or '6X' '88', '89'
GET CHALLENGE '0X' or '4X' or '6X' '84'
TERMINAL CAPABILITY '8X' or 'CX' or 'EX' 'AA'
TERMINAL PROFILE '80' '10'
ENVELOPE '80' 'C2'
FETCH '80' '12'
TERMINAL RESPONSE '80' '14'
MANAGE CHANNEL '0X' or '4X' or '6X' '70'
MANAGE SECURE CHANNEL '0X' or '4X' or '6X' '72'
TRANSACT DATA '0X' or '4X' or '6X' '75'
Transmission oriented APDUs
GET RESPONSE '0X' or '4X' or '6X' 'C0'

四、掉卡实例

从MD log中看,在15:48:48:578 时刻,APDU_tx 0: 80 F2 00 00 00 cmd下发后,卡一直没有回复(CMD_TOUT)
在 15:48:51:058 时刻开始进行Fast_Recovery,但三次都失败了。
在 15:48:52:698 时刻开始full recovery,没30s尝试一次,直到log结束都未能将卡救起。
1100910, 0, 291950691, 15:48:48:578 2017/04/18, MOD_SIM, , TRACE_GROUP_3, APDU_tx 0: 80 F2 00 00 00 F2 F2 F2 F2 F2 FC 1E F2 F2 F2 F2
1100914, 0, 291950700, 15:48:48:578 2017/04/18, MOD_SIM_DRV, , TRACE_INFO, [SIM_DRV:0]L1sim_Cmd_Layer_MTK P3=0 txSize=5, rxData!=NULL, *rxSize=256
1107010, 0, 291975333, 15:48:50:058 2017/04/18, MOD_SIM_DRV, , TRACE_INFO, [SIM_DRV:0][ERR]CMD_TOUT
1107031, 0, 291975343, 15:48:50:058 2017/04/18, MOD_SIM_DRV, , TRACE_INFO, turn off vsim0
1107424, 0, 291977068, 15:48:50:258 2017/04/18, MOD_SIM, MOD_SIM, SIM_SIM_SAP, MSG_ID_SIM_ERROR_IND
1107425, 0, 291977069, 15:48:50:258 2017/04/18, MOD_SIM, , TRACE_INFO, STATUS => 00 00
1107674, 0, 291978164, 15:48:50:258 2017/04/18, MOD_SIM_DRV, , TRACE_INFO, [SIM_DRV:0][ERR]No ATR
1107962, 0, 291980197, 15:48:50:458 2017/04/18, MOD_SIM_DRV, , TRACE_INFO, [SIM_DRV:0][ERR]No ATR
    ...
    
1109708, 0, 291989284, 15:48:51:058 2017/04/18, MOD_NIL, , TRACE_INFO, SIM_Fast_Recovery_fail
1112529, 0, 292001566, 15:48:51:858 2017/04/18, MOD_NIL, , TRACE_INFO, SIM_Fast_Recovery_fail
1115034, 0, 292013800, 15:48:52:698 2017/04/18, MOD_NIL, , TRACE_INFO, SIM_Fast_Recovery_fail
1115084, 0, 292013805, 15:48:52:698 2017/04/18, MOD_SIM, , TRACE_GROUP_3, sim_start_recovery_timer()
1115348, 0, 292013836, 15:48:52:698 2017/04/18, MOD_NIL, , TRACE_INFO, [AT_U p19, s8]+ESIMS: 0,13    
1140430, 0, 292494789, 15:49:23:426 2017/04/18, MOD_SIM, , TRACE_GROUP_3, sim_start_recovery_timer()
1142442, 0, 292975773, 15:49:54:209 2017/04/18, MOD_SIM, , TRACE_GROUP_3, sim_start_recovery_timer()

从您的问题描述:
>> 掉SIM卡》开关飞行,开关机未恢复》关机插拔卡恢复
推断比较倾向于卡与卡座接触不良。具体请对照《sim_debug_sop》进行排查。

五、拔卡中断上报前发生掉卡事件,导致延时上报拔卡事件

在拔卡中断上报前,已经出现掉卡了,所以掉卡流程先启动救卡,再出来拔卡中断。

log path: MTKlog@mdlog1@MDLog1_2017_0517_165820

PS    334415    10141    16:59:10:410    PHB_2 - SIM_2    MSG_ID_SIM_READ_REQ        
PS    334417    10141    16:59:10:410    SIM_2    SIM_READ_RECORD : length: 5        
PS    334418    10141    16:59:10:410    SIM_2    APDU_tx 0: 00 B2 CD 04 01 F2 F2 F2 F2 F2 00 00 00 00 00 00        
PS    345001    10323    16:59:11:210    SIM_2    READ RECORD rec# 205 size: 1 => 00 00        
PS    347269    10359    16:59:11:410    SIM    SIM PLUG OUT(1) -> PS(1)        
PS    347270    10359    16:59:11:410    DRV_HISR - SIM_2    MSG_ID_SIM_PLUG_OUT_IND        

六、SIM卡初始化时掉卡频繁识别为sim类型引发的问题

A0 A4这个select 为啥CLA位为A0,好像和协议不太一样啊
-->
对于USIM卡,basic channel CLA为00;
对应SIM卡, basic channel CLA为A0;
可以看到开机log,这张卡开机的时候就发生了掉卡导致读取相应文件时没有读到,当做SIM卡处理。
等再做recovery的时候,由于之前已经检测过识别卡类型的情况,所以就直接沿用,还是当做SIM卡处理。
从整个log来看是开机初始化时就掉卡所有出现了识卡异常。

Type    Index    Time    Local Time    Module    Message    Comment    Time Different
SYS    10047    606    20:19:51:245    NIL    [AT_I p18, s8]AT+ESIMS
        
PS    10063    606    20:19:51:245    L4C - SIM    MSG_ID_SIM_RESET_REQ        
PS    10104    643    20:19:51:245    SIM_DRV    [SIM_DRV]:SIM0 ATR= 3B9F95801FC78031E073FE211B675348434F5F01019B        
SYS    10213    643    20:19:51:245    NIL    SIM_Reset in CDMA Detection        
SYS    10237    670    20:19:51:445    NIL    SIM: 0000        
SYS    10239    670    20:19:51:445    NIL    Card without CDMA folder        
SYS    10252    670    20:19:51:445    NIL    SIM: 0000        
SYS    10254    670    20:19:51:445    NIL    Card without GSM folder        
SYS    10266    670    20:19:51:445    NIL    SIM: 0000        
SYS    10268    670    20:19:51:445    NIL    CDMA detect SIM insert        
SYS    10414    721    20:19:51:645    NIL    Skip try USIM        
SYS    10633    790    20:19:52:045    NIL    [AT_R p18, s8]+ESIMS: 1    
PS    14379    1118    20:19:53:765    SIM - SIM    MSG_ID_SIM_ERROR_IND        
PS    14380    1118    20:19:53:765    SIM    SIM_FILE_SELECTED: 3F 00 => 00 00        
SYS    14401    1118    20:19:53:765    NIL    SIM_Fast_Recovery_fail        
    
PS    34704    7119    20:20:23:810    TIMER - SIM    MSG_ID_TIMER_EXPIRY        
PS    34766    7168    20:20:24:010    SIM_DRV    [SIM_DRV]:SIM0 ATR= 3B9F95801FC78031E073FE211B675348434F5F01019B        
SYS    34877    7168    20:20:24:010    NIL    Skip try USIM        
PS    34896    7175    20:20:24:010    SIM    SIM_FILE_SELECTED: 7F 20 => 90 00        
PS    35056    7229    20:20:24:210    SIM_DRV    [SIM_DRV]:SIM0 ATR= 3B9F95801FC78031E073FE211B675348434F5F01019B        
PS    35187    7239    20:20:24:410    SIM    SIM_FILE_SELECTED: 7F 20 => 90 00        
SYS    35353    7239    20:20:24:410    NIL    [AT_U p18, s8]+ESIMS: 1,14        
SYS    35597    7255    20:20:24:410    NIL    [AT_U p18, s8]+EUSIM: 0, 2        

除第一次掉卡,出现fast recovery一直失败,最终在full recovery将卡救起。其他都在fast recovery阶段将卡救起。
14310, 676, 1118, 20:19:53:765 2017/05/10, MOD_SIM, , TRACE_GROUP_3, APDU_tx 0: A0 A4 00 00 02 3F 00 F2 F2 F2 F2 45 46 55 4E 3D
14312, 676, 1118, 20:19:53:765 2017/05/10, MOD_SIM_DRV, , TRACE_INFO, [MOD_SIM_DRV] CMD header: a0 a4 0 0 2, txSize:7, rxSize:0
14372, 676, 1118, 20:19:53:765 2017/05/10, MOD_SIM_DRV, , TRACE_INFO, SIM0 Get SW=0x0000 from SIM Controller!!!!
14398, 676, 1118, 20:19:53:765 2017/05/10, MOD_NIL, , TRACE_INFO, SIM: 0000
14401, 676, 1118, 20:19:53:765 2017/05/10, MOD_NIL, , TRACE_INFO, SIM_Fast_Recovery_fail
14552, 3561, 1120, 20:19:53:765 2017/05/10, MOD_NIL, , TRACE_INFO, [AT_U p18, s8]+ESIMS: 0,13
35353, 1760827, 7239, 20:20:24:410 2017/05/10, MOD_NIL, , TRACE_INFO, [AT_U p18, s8]+ESIMS: 1,14
    
48557, 1761163, 7564, 20:20:26:010 2017/05/10, MOD_SIM_DRV, , TRACE_INFO, [MOD_SIM_DRV] CMD header: a0 a4 0 0 2, txSize:7, rxSize:0
48612, 1761164, 7565, 20:20:26:010 2017/05/10, MOD_SIM_DRV, , TRACE_INFO, SIM0 Get SW=0x0000 from SIM Controller!!!!
48620, 1761164, 7565, 20:20:26:010 2017/05/10, MOD_SIM, , TRACE_INFO, SIM_FILE_SELECTED: 7F 10 => 00 00
48618, 1761164, 7565, 20:20:26:010 2017/05/10, MOD_NIL, , TRACE_INFO, SIM: 0000
49308, 1761263, 7639, 20:20:26:410 2017/05/10, MOD_NIL, , TRACE_INFO, SIM_Fast_Recovery success

102529, 462991, 19327, 20:21:24:820 2017/05/10, MOD_SIM, , TRACE_GROUP_3, APDU_tx 0: A0 A4 00 00 02 3F 00 F2 F2 F2 F2 F2 F2 F2 F2 30
102531, 462991, 19327, 20:21:24:820 2017/05/10, MOD_SIM_DRV, , TRACE_INFO, [MOD_SIM_DRV] CMD header: a0 a4 0 0 2, txSize:7, rxSize:0
102648, 462991, 19327, 20:21:24:820 2017/05/10, MOD_SIM_DRV, , TRACE_INFO, SIM0 Get SW=0x0000 from SIM Controller!!!!
102660, 462992, 19328, 20:21:24:820 2017/05/10, MOD_SIM, MOD_MM, PS_SIM_SAP, MSG_ID_SIM_AUTHENTICATE_CNF
    Local_Parameter --> Len = 346, Addr = 0xF22FB8A4
        sim_authenticate_cnf_struct = (struct)
            ref_count = 0x01
            lp_reserved = 0x01
            msg_len = 0x015a
            result = SIM_CMD_FAIL (enum 2561)
            status_word = 0x0000
105054, 463416, 19719, 20:21:26:640 2017/05/10, MOD_NIL, , TRACE_INFO, SIM_Fast_Recovery_fail
105446, 463488, 19786, 20:21:27:040 2017/05/10, MOD_NIL, , TRACE_INFO, SIM_Fast_Recovery success
...

六、关于SIM卡上电以及一些中断状态的确认

1. 想问下贵司的哪条log表示对SIM卡进行上电,是那条turn on vsim吗?
【MTK】是的.
2253417, 134907, 115653, 15:22:59:180 2017/06/05, MOD_SIM_DRV, , TRACE_INFO, vsim1:3.0V
2253418, 134907, 115653, 15:22:59:180 2017/06/05, MOD_SIM_DRV, , TRACE_INFO, turn on vsim1

2. int status和[SIM_GEN1] file 2这些代表什么意思?
【MTK】int status是读取的sim中断,具体含义请参考下面代码:
file:icc_switchContril_mtk_1.c
void usim_hisr2(void)
{
...
int_status = SIM_Reg(SIM0_BASE_ADDR_MTK + SIM_STS_MTK);
...
if(int_status & SIM_STS_RX)
    {
        usim_rx_handler(int_status, hw_cb);
    }
...
}

//SIM_STS
#define     SIM_STS_TX         0x0001
#define     SIM_STS_RX         0x0002
#define     SIM_STS_OV         0x0004
#define     SIM_STS_TOUT         0x0008
#define     SIM_STS_TXERR         0x0010
#define     SIM_STS_NATR         0x0020
#define     SIM_STS_SIMOFF         0x0040
#define     SIM_STS_T0END 0x0080
#define     SIM_STS_RXERR 0x0100
#define     SIM_STS_T1END                0x0200
#define    SIM_STS_EDCERR                0x0400

file2这行log打印地方如下,fffffffd 表示没有收到ATR(USIM_NO_ATR = -3).

static kal_bool usim_select_power(usim_power_enum ExpectVolt, sim_HW_cb *hw_cb)
{{
...
drv_trace8(TRACE_GROUP_4, SIM_GEMINI_GEN1, FILE_SWITCHCONTROL1, __LINE__,
            usim_dcb->ev_status, usim_dcb->power,
            SIM_Reg(SIM0_BASE_ADDR_MTK + SIM_CONF_MTK), SIM_Reg(SIM0_BASE_ADDR_MTK + SIM_COUNT_MTK),
            SIM_Reg(SIM0_BASE_ADDR_MTK + SIM_CTRL_MTK), drv_get_current_time()
        );
...
}
typedef enum{
    USIM_NO_ERROR = 0,

    // expected status
    USIM_WAITING_EVENT = 1,        // initial wait event status
    USIM_BLOCK_REC = 2,        // successfully received a complete block
    USIM_POWER_OFF = 3,        // successfully powered off
    USIM_ATR_REC = 4,            // successfully reveived all ATR
    USIM_S_BLOCK_REC = 5,    // successfully reveived S RESP

    // error status
    USIM_NO_INSERT = -1,
    USIM_VOLT_NOT_SUPPORT = -2,
    USIM_NO_ATR = -3,
    USIM_TS_INVALID = -4,
    USIM_ATR_ERR = -5,
    USIM_INVALID_ATR = -6,
    USIM_PTS_FAIL = -7,
    USIM_RX_INVALID = -8,    // EDC error or parity error
    USIM_BWT_TIMEOUT = -9,
    USIM_DATA_ABORT = -10,
    USIM_DEACTIVATED = -11,
    USIM_S_BLOCK_FAIL = -12,
    USIM_INVALID_WRST = -13,
    USIM_GPT_TIMEOUT = -14
}usim_status_enum;

© 著作权归作者所有

HouWeiGui
粉丝 4
博文 42
码字总数 52381
作品 0
深圳
程序员
私信 提问
一文彻底解决iOS中键盘回落后留白问题

最近做的一个H5刚开开心心提测就被QA一顿怼😭,当input输入完成后页面简直卡成翔💩,当我接过手机亲自测试时慌的一批😢,顿时开始怀疑人生😏,马上开始进入紧张的排查中😊,经过两...

天道酬勤Lewis
06/12
0
0
用数据帮公司省1000万!看看你会不会错过机会

感谢关注天善智能,走好数据之路↑↑↑ 欢迎关注天善智能,我们是专注于商业智能BI,人工智能AI,大数据分析与挖掘领域的垂直社区,学习,问答、求职一站式搞定! 对商业智能BI、大数据分析挖...

天善智能
2018/05/11
0
0
iOS 面试全方位剖析 -- UI视图篇(二)

UITableView相关 事件传递&视图响应 图像显示原理 卡顿&掉帧 绘制原理&异步绘制 离屏渲染 面试问题总结 图像显示原理 具体的看一下CPU和GPU做了哪些事,看下图 } 此时的堆栈...

PetitBread
2018/05/10
0
0
Android GPU呈现模式原理及卡顿掉帧浅析

APP开发中,卡顿绝对优化的大头,Google为了帮助开发者更好的定位问题,提供了不少工具,如Systrace、GPU呈现模式分析工具、Android Studio自带的CPU Profiler等,主要是辅助定位哪段代码、哪...

看书的小蜗牛
01/03
0
0
有种速度让你望尘莫及 | 手机QQ及Qzone速度优化实践

作者介绍: 黄浩宇 现就职于腾讯社交网络运营部,负责SNG社交网络业务移动类产品的业务运维工作,如QQ、Qzone业务优化及开发。 此前任职于阿里巴巴,负责天猫商城活动类业务的运维工作,如天...

yard521
2016/09/19
0
0

没有更多内容

加载失败,请刷新页面

加载更多

zk中ToBeAppliedRequestProcessor解析

ToBeAppliedRequestProcessor在Leader中 在已处理事务和最后处理事务处理器之间,处理器链上下一个是FinalRequestProcessor public void processRequest(Request request) throws RequestPro...

writeademo
8分钟前
1
0
Allegro快捷键设置-PCB环境

立题简介: 内容:简单介绍Allegro绘制的PCB环境下的快捷键; 来源:实际使用得出; 作用:对Allegro绘制PCB快捷键进行介绍; PCB环境:Cadence 16.6; 立题详解: 对“allegro”板而言,其在...

demyar
10分钟前
1
0
idea maven web项目启动build时报错java.lang.NullPointerException

之前还好好的,重启一下idea就报这个错了,大概率是tomcat没杀掉端口被占用了,在tomcat配置中更换一下sever端口就好了

宇辰OSC
13分钟前
1
0
weed3-2.3.1.查询之输出

Weed3 一个超轻量级ORM框架(只有0.1Mb哦) 源码:https://github.com/noear/weed3 源码:https://gitee.com/noear/weed3 查询可是个复杂的话题了,可能我们80%的数据库处理都在查询。 今天先...

刘之西东
13分钟前
1
0
【Android JetPack系列】数据绑定:DataBinding

参考MVVM

Agnes2017
22分钟前
2
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部