掉卡問題的分析總結

1、mtk平臺掉卡:c#

相關AT:debug

主動上報:AT+ESIMScode

開關飛行模式: AT+EPOFhtm

切換主卡: AT+ES3G=2, 7事件

卡類型的上報:EUSIMip

掉卡後流程異常:ci

「AT+ECSRA=2,1,0,1,1,0」沒有返回,引發mode switch 被pending沒法上報最終卡的狀態。文檔

共卡座的配置:get

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

屬性查看: [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平臺的救卡機制介紹:

一、從log看既然已經顯示是DCL_USIM_NO_INSERT,也就是未插卡狀態,那麼這個掉卡的時候是否會觸發熱插拔機制呢?非要等到每次終端去查卡的狀態纔會發現掉卡了嗎。
=>這裏顯示DCL_USIM_NO_INSERT可能會誤導,它真實的意思是SIM卡檢測失敗,上層就不會再走SIM卡的init流程,而且報告沒檢測到卡。但SIM卡還在卡槽裏面。因此這裏跟熱插拔沒有關係了。

二、你說每次發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。

三、每次在reset命令先後都會看到turn on vsim0 ,turn off vsim0,這兩條命令什麼意思,是否對救卡有影響
=>所謂reset就是power on reset,意指要對SIM卡作「掉電->上電->reset」的操做,就是對應的「turn on vsim0 ,turn off vsim0」。這是救卡的正常動做。

2、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

3、轉自別人博客的關於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'

4、掉卡實例

從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》進行排查。

5、拔卡中斷上報前發生掉卡事件,致使延時上報拔卡事件

在拔卡中斷上報前,已經出現掉卡了,因此掉卡流程先啓動救卡,再出來拔卡中斷。

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        

6、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
...

6、關於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;

相關文章
相關標籤/搜索