掉卡问题的分析总结-CSDN博客

2019独角兽企业重金招聘Python工程师标准>>>

一、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;