Hi. I am facing some issues regarding +CSIM command, where it seems like EC800G-CN is unable to properly get a long APDU(probably more than 256 bytes) replied by the sim card.
ATI
Quectel
EC800G
Revision: EC800GCNLDR01A07M04
OK
Below describes the problem:
this is the last APDU we are trying to insert into the sim card, and is succesful:
AT+CSIM=286,"81E291038A09BC69425A31F1A10220087DB85D52BC712267480EA445A30FAE472AF75FE9BDEABD7EC028C94B498B06A05E80203532444636454231364541433143433835323041463836433745344136393941A13A800468822260A12880030500008103080000820301000083030100008403020000850302000086030900008703020000820868822260867641F8"
+CSIM: 4,"6100"
OK
however since the respond was 6100 (00 means unknown length), than the application will continue to GET the reply with 00 length indicator as well. But we believe the replied APDU is not complete.
[DBG ][2025-03-13 19:34:12.214][0xb66e5530][ 190 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2025-03-13 19:34:12.308][0xb66e5530][ 293 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 4,"6100"
OK
).
[DBG ][2025-03-13 19:34:12.310][0xb66e5530][ 190 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2025-03-13 19:34:12.376][0xb66e5530][ 293 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 4,"6100"
OK
).
[DBG ][2025-03-13 19:34:12.378][0xb66e5530][ 190 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2025-03-13 19:34:12.452][0xb66e5530][ 293 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 4,"6100"
OK).
[DBG ][2025-03-13 19:34:12.458][0xb66e5530][ 190 rt_plat_port_at.c]rt_port_impl_at_command cmd:(
AT+CSIM=10,"01C0000000"
).
[DBG ][2025-03-13 19:34:12.524][0xb66e5530][ 293 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 4,"6100"
OK
).
[DBG ][2025-03-13 19:34:12.526][0xb66e5530][ 190 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2025-03-13 19:34:12.591][0xb66e5530][ 293 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 4,"6100"
OK).
[DBG ][2025-03-13 19:34:12.594][0xb66e5530][ 190 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2025-03-13 19:34:12.660][0xb66e5530][ 293 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 4,"611C"
OK
).
since the last character of the APDU is 1C then the application will follow and get the reply with 1C length indicator as well.
This is where the confusion begins, because we cannot understand why the previous attempt was empty and all we can see is only 6100
[DBG ][2025-03-13 19:34:12.662][0xb66e5530][ 190 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C000001C"
).
[DBG ][2025-03-13 19:34:12.704][0xb66e5530][ 293 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 60,"607464E9C5FA6F9DDB80329EBB68F09BC1B6A2047A1328D31CAC25F59000"
OK
For a comparison, we have a record of few similar tests done on EC20F model which were surprisingly successful. Below log shows similar scenario, where the application write the last APDU to sim card, and on every GET command to the sim card replied with a complete APDU result and are quite long on each segment.
[DBG ][2024-07-17 03:14:17.101][0xb63a8460][ 250 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=412,"81E29103C9756C742E7265647465612E696F2F63692F63726C300A06082A8648CE3D040302034700304402205CEE0605BFD37ADB11A3A36E10D6DAC08425FE7E2604BF5CFD073A403CFAB02A02207752B10C98AE35A47357934392BC748E370AC8BBBD8F936029EB5A2C4F2A70C7A05E80204642463236363942354245373646463745354330433243303430373541453537A13A800468551040A12880030500008103080000820301000083030100008403020000850302000086030900008703020000820868551040801211F5"
).
+CSIM: 4,"6100"
OK
).
[DBG ][2024-07-17 03:14:18.081][0xb63a8460][ 250 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2024-07-17 03:14:18.141][0xb63a8460][ 353 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 516,"BF38820715A08207113082013A8008000000000015F70C830F717561726B2E7265647465612E696F8410D20A3A53535AA2861B7D88F6707A57EDBF2281A9810302030182030202028303202100840F8101008204000582828304000013EA8505067F36DBC086030F0000870302030088020192A92C041473FCA0559907C005424825CA06F6195CC06300E4041481370F5125D0B1D408D4C3B232E6D25E795BEBFBAA2C041473FCA0559907C005424825CA06F6195CC06300E4041481370F5125D0B1D408D4C3B232E6D25E795BEBFB990206C004030100000C0D47442D4E472D55502D31323233A05E80204642463236363942354245373646463745354330436100"
OK
).
[DBG ][2024-07-17 03:14:18.141][0xb63a8460][ 250 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2024-07-17 03:14:18.211][0xb63a8460][ 353 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 516,"3243303430373541453537A13A800468551040A12880030500008103080000820301000083030100008403020000850302000086030900008703020000820868551040801211F55F3740CC4475FFFB2223D381104821C83AC22E1A881985F1DBF9968647E3D753A24FBE19C962B02A633C87C49651E9212BD733620DB591EB180A5ACD68D98B61C8811C30820248308201EDA0030201020212008904903200000100000018341261138501300A06082A8648CE3D040302307C310B300906035504061302434E3121301F060355040B0C18436F6E6E656374697669747920616E642044657669636573312E302C060355040A0C254769657365636B65446576726100"
OK
).
[DBG ][2024-07-17 03:14:18.211][0xb63a8460][ 250 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2024-07-17 03:14:18.271][0xb63a8460][ 353 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 516,"69656E74204D6F62696C6520536563757269747920476D6248311A301806035504030C11526564746561204D6F62696C652045554D3022180F32303135303930313132303030305A180F39393939313233313233353935395A304E3121301F060355040A0C18472B44204D6F62696C6520536563757269747920476D6248312930270603550405132038393034393033323030303030313030303030303138333431323631313338353059301306072A8648CE3D020106082A8648CE3D03010703420004F7CEAF8FD92DBD39D50FF7BB55BFC7FB5DEE0ECADD1928395A358764F7A30E5697E4754312FEBA56083888B2A50B038BAE277BB3F24DFDC42218E4996100"
OK
).
[DBG ][2024-07-17 03:14:18.271][0xb63a8460][ 250 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2024-07-17 03:14:18.331][0xb63a8460][ 353 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 516,"114F84CCA3793077300E0603551D0F0101FF040403020780300C0603551D130101FF0402300030170603551D200101FF040D300B3009060767811201020101301D0603551D0E041604140B8725A89107C7AF3967076D8A84CBAA4FAA2512301F0603551D230418301680143C8BFF07329554C577FD0FF7E685CF0397EF93E4300A06082A8648CE3D0403020349003046022100D0B4B27751B2C344B8FC65725FC8218667A0B051567634478BC0BC0C616598DE0221008D6E45A05184B27C4C4E4534C2E9001D557A09C5CE7F975CB112AE4643B7745630820340308202E6A003020102020463B7ABE2300A06082A8648CE3D040302308183310B3009060355046100"
OK
).
[DBG ][2024-07-17 03:14:18.332][0xb63a8460][ 250 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2024-07-17 03:14:18.401][0xb63a8460][ 353 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 516,"061302434E3111300F06035504080C085368656E7A68656E311B3019060355040A0C12526564746561204D6F62696C6520496E632E31293027060355040B0C20526564746561204D6F62696C65204365727469666963617465204973737565723119301706035504030C10526564746561204D6F62696C65204349301E170D3233303130363035303433345A170D3433303130363035303433345A307C310B300906035504061302434E3121301F060355040B0C18436F6E6E656374697669747920616E642044657669636573312E302C060355040A0C254769657365636B654465767269656E74204D6F62696C6520536563757269747920476D6248311A306100"
OK
).
[DBG ][2024-07-17 03:14:18.401][0xb63a8460][ 250 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2024-07-17 03:14:18.461][0xb63a8460][ 353 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 516,"1806035504030C11526564746561204D6F62696C652045554D3059301306072A8648CE3D020106082A8648CE3D03010703420004644A2110AB3F3C3CDB0E8CAA3DB6ED6A8412200AEE5F97874015671327EF8420B9B8135A740B21BFF35AA2E06CF23E330A1A9DA4B0566EC4EBDBD9012D9B2B33A382014C3082014830170603551D200101FF040D300B300906076781120102010230120603551D130101FF040830060101FF020100300E0603551D0F0101FF0404030201063081800603551D1E0101FF04763074A0723070A46E306C3121301F060355040A0C18472B44204D6F62696C6520536563757269747920476D62483111300F0603550405130838396100"
OK
).
[DBG ][2024-07-17 03:14:18.461][0xb63a8460][ 250 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C0000000"
).
[DBG ][2024-07-17 03:14:18.521][0xb63a8460][ 353 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 516,"3034393033323121301F060355040A0C18472B44204D6F62696C6520536563757269747920476D62483111300F06035504051308383930343930333830150603551D11040E300C880A2B06010401DC0F680109302F0603551D1F042830263024A022A020861E68747470733A2F2F7661756C742E7265647465612E696F2F63692F63726C301F0603551D2304183016801473FCA0559907C005424825CA06F6195CC06300E4301D0603551D0E041604143C8BFF07329554C577FD0FF7E685CF0397EF93E4300A06082A8648CE3D0403020348003045022100B93376F65D44BCCC6ACFD682E34F4E8FB7742DC37B2062088A9CDC23A947BC6F02207BBA2E346074611A"
OK
).
similar to the faulty case with EC800G-CN, the application respond to the 1A length indicator and then try to GET the last one with 1A . as result, we are seeing a complete APDU (short becuse of the remaining APDU)
[DBG ][2024-07-17 03:14:18.521][0xb63a8460][ 250 rt_plat_port_at.c]rt_port_impl_at_command cmd: (
AT+CSIM=10,"01C000001A"
).
[DBG ][2024-07-17 03:14:18.601][0xb63a8460][ 353 rt_plat_port_at.c]rt_port_impl_at_command rsp: (
+CSIM: 56,"64E9C5FA6F9DDB80329EBB68F09BC1B6A2047A1328D31CAC25F59000"
OK
).
So, based on above description and comparison, we are guessing that there is a bug on EC800G-CN where it is unable to capture a proper reply when the sim card reply with APDU more than 256 bytes.
I would appreciate that QUECTEL can give me a feedback, and I would love to help if there is anything I can do to provide more information or further investigation.
thank you
Looking forward to your response.