Boron LTE throwing SIM not inserted error (bad HW?)

SockThief · March 30, 2020, 9:33pm

Hi i have a boron LTE, and as im outside the US, I have to switch away from the MFF2 SIM.

No matter what I do, it won’t connect. I tested the SIM in a few other devices and it failed, so wrote off the SIM as a dud. Grabbed a new SIM, tested it and its working fine in every other device i have, throw it in the boron and no connection.

flashed clouddebug, and seeing

0000208644 [hal] INFO: Using external Nano SIM card
0000208644 [hal] INFO: Using external Nano SIM card
0000208645 [ncp.at] TRACE: > AT+CPIN?
0000208653 [ncp.at] TRACE: < +CME ERROR: SIM not inserted

take the SIM out, and test, it works fine.

found a post here with similar symptoms (Boron LTE Fails to Connect) so flashed v1.1.0-rc.2

particle flash --usb boron-system-part1@1.1.0-rc.2.bin
$ particle serial inspect
Platform: 13 - Boron
Modules
  Bootloader module #0 - version 501, main location, 49152 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
  System module #1 - version 1101, main location, 671744 bytes max size
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      Bootloader module #0 - version 201
  User module #1 - version 6, main location, 131072 bytes max size
    UUID: 4FFE696644B5077D7AE0432B8E1F17D39D0A710359AEA4A5390E64DD7992E9A5
    Integrity: PASS
    Address Range: PASS
    Platform: PASS
    Dependencies: PASS
      System module #1 - version 1101

i’ve tested the SIM in various orientations to no success (though it is hard to tell the orientation via the docs or silkscreen) - can anyone confirm the SIM orientation?

looking at the R410M datasheet, GPIO5 is the SIM detection pin (which would connect to the SIM holders physical presence switch) but according to the block diagram in the datasheet (and the schematics) this pin is not connected (i guess this makes sense with the dual SIM setup with the FSA2567) so it’s not failing to detect the SIM in the socket, it appears to not be reading the SIM.

Given that the SIM i am using works in every other device, im starting to lean towards a HW fault, unless someone has a suggestion of what im doing wrong? I can perhaps throw another SIM (from my 4G HotSpot) in and it should at least pass SIM insertion error I guess and throw a connection error later.

ScruffR · March 31, 2020, 6:12am

The Boron is not using the same type LTE as your hotspot or phone would.

Which country are you in and what provider does the SIM use?

SockThief · March 31, 2020, 7:44am

hi @ScruffR

yeah, i understand the different variants of LTE, my thinking was to at least pass the “no SIM inserted” error - i.e.: if the boron fails to connect to the network due to no carrier etc, then at least the HW seems OK, then i have an issue somewhere else.

I am in Sweden, we have an LTE-M1 network, and the SIM is LTE-M1 enabled (confirmed with the carrier) - I’ve got another nRF9160 (Thingy:91) so ill test the SIMs in that as well

SockThief · March 31, 2020, 10:30pm

have done some more testing during the day and can confirm that the Boron board itself appears to be ok.

I found another Nano LTE-M SIM, and that doesn’t throw an error on SIM not being inserted

starting tests...
turning cellular on...
deviceID=e00fce688ce16cf546078933
manufacturer=u-blox
model=SARA-R410M-02B
firmware version=L0.0.00.00.05.06 [Feb 03 2018 13:00:41]
ordering code=SARA-R410M-02B
IMEI=352753090289172
IMSI=u-blox
ICCID=8931080019073496748
0000036684 [app] INFO: enabling trace logging
0000036684 [ncp.at] TRACE: > AT+CGDCONT?
0000036733 [ncp.at] TRACE: < +CGDCONT: 1,"IP","apn","0.0.0.0",0,0,0,0
0000036734 [ncp.at] TRACE: < OK
0000036734 [ncp.at] TRACE: > AT+CSQ
0000036783 [ncp.at] TRACE: < +CSQ: 99,99
0000036783 [ncp.at] TRACE: < OK
attempting to connect to the cellular network...
0000036786 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000036786 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000036787 [hal] TRACE: PPP netif -> 8
0000036787 [net.ifapi] INFO: Netif pp3 state UP
0000036787 [net.ifapi] INFO: Netif pp3 state UP
0000036789 [hal] TRACE: PPP thread event LOWER_DOWN
0000036789 [hal] TRACE: PPP thread event ADM_DOWN
0000036789 [hal] TRACE: PPP thread event ADM_UP
0000036790 [hal] TRACE: State NONE -> READY
0000036792 [ncp.at] TRACE: > AT+CGDCONT=1,"IP","apn"
0000036794 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000036794 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000036833 [ncp.at] TRACE: < OK
0000036834 [ncp.at] TRACE: > AT+CEREG=2
0000036883 [ncp.at] TRACE: < OK
0000036883 [hal] TRACE: NCP connection state changed: 1
0000036884 [net.pppncp] TRACE: NCP event 2
0000036884 [net.pppncp] TRACE: State changed event: 1
0000036885 [hal] TRACE: PPP thread event LOWER_DOWN
0000036885 [ncp.at] TRACE: > AT+COPS=0,2
0000036933 [ncp.at] TRACE: < OK
0000036934 [ncp.at] TRACE: > AT+CEREG?
0000036934 [ncp.at] TRACE: < +CEREG: 2
0000036983 [ncp.at] TRACE: < +CEREG: 2,2
0000036984 [ncp.at] TRACE: < OK
0000051984 [ncp.at] TRACE: > AT+CEREG?
0000052033 [ncp.at] TRACE: < +CEREG: 2,2
0000052033 [ncp.at] TRACE: < OK
0000052134 [ncp.at] TRACE: < +CEREG: 0
0000067034 [ncp.at] TRACE: > AT+CEREG?
0000067083 [ncp.at] TRACE: < +CEREG: 2,0
0000067083 [ncp.at] TRACE: < OK
0000082084 [ncp.at] TRACE: > AT+CEREG?
0000082133 [ncp.at] TRACE: < +CEREG: 2,0
0000082133 [ncp.at] TRACE: < OK
0000091937 [ncp.at] TRACE: < +CEREG: 2
0000097137 [ncp.at] TRACE: > AT+CEREG?
0000097195 [ncp.at] TRACE: < +CEREG: 2,2
0000097195 [ncp.at] TRACE: < OK
0000112196 [ncp.at] TRACE: > AT+CEREG?
0000112253 [ncp.at] TRACE: < +CEREG: 2,2
0000112253 [ncp.at] TRACE: < OK
0000127256 [ncp.at] TRACE: > AT+CEREG?
0000127307 [ncp.at] TRACE: < +CEREG: 2,2
0000127307 [ncp.at] TRACE: < OK
0000142321 [ncp.at] TRACE: > AT+CEREG?
0000142345 [ncp.at] TRACE: < +CEREG: 2,2
0000142346 [ncp.at] TRACE: < OK
0000142446 [ncp.at] TRACE: < +CEREG: 0
0000145316 [sys.power] TRACE: Battery state CHARGED -> DISCONNECTED
0000157352 [ncp.at] TRACE: > AT+CEREG?
0000157399 [ncp.at] TRACE: < +CEREG: 2,0
0000157399 [ncp.at] TRACE: < OK
0000172499 [ncp.at] TRACE: > AT+CEREG?
0000172549 [ncp.at] TRACE: < +CEREG: 2,0
0000172549 [ncp.at] TRACE: < OK
0000187649 [ncp.at] TRACE: > AT+CEREG?
0000187699 [ncp.at] TRACE: < +CEREG: 2,0
0000187699 [ncp.at] TRACE: < OK
0000202799 [ncp.at] TRACE: > AT+CEREG?
0000202849 [ncp.at] TRACE: < +CEREG: 2,0
0000202849 [ncp.at] TRACE: < OK
0000205316 [sys.power] TRACE: re-enabling charging
0000205350 [sys.power] TRACE: Battery state UNKNOWN -> CHARGED
0000217850 [ncp.at] TRACE: > AT+CEREG?
0000217900 [ncp.at] TRACE: < +CEREG: 2,0
0000217900 [ncp.at] TRACE: < OK
0000232901 [ncp.at] TRACE: > AT+CEREG?
0000232950 [ncp.at] TRACE: < +CEREG: 2,0
0000232950 [ncp.at] TRACE: < OK
0000247951 [ncp.at] TRACE: > AT+CEREG?
0000248000 [ncp.at] TRACE: < +CEREG: 2,0
0000248000 [ncp.at] TRACE: < OK

good news! but swapping the original SIM back in, seems to be not inserted. And again, testing that SIM in other devices works fine. So it would seem the combination of that sim and particle boron lte is causing issues.

I’ve put the SIMs side by side, and there is nothing i can see that would cause issues - if anything, physically, the SIM that works has smaller contact areas.

One other thing I can think of then is perhaps a SIM voltage issue? From what I can see in the block diagram, schematics and datasheets, and my understanding of the way a terminal selects the SIM voltage, this shouldn’t be an issue - it should start at 1.8v, then try 3v and 5v until one works - and since the R410m is a being powered by Vsys at 5v this shouldn’t be an issue

i’ve just spent the last few hours backtracking the device-os code from the trace information - thinking that either 1) i can find where the SIM insertion test is and hence why it’s failing or 2) it might be a bad mapping between error codes and it’s not actually a “SIM not inserted error”

line 860 of https://github.com/particle-iot/device-os/blob/af50fb1b6017412c3719d876f602500a2c47dd23/hal/src/boron/network/sara_ncp_client.cpp would seem to suggest that numeric error codes from the R410 are used

i can see at line 772, the R410 GPIOs are read. GPIO 2 (#23) is the sim select switch, and from my trace i can see 0 is being returned, indicating the external sim - so thats correct

0000487059 [ncp.at] TRACE: > AT+UGPIOC?
0000487066 [ncp.at] TRACE: < +UGPIOC:
0000487066 [ncp.at] TRACE: < 16,255
0000487067 [ncp.at] TRACE: < 19,255
0000487068 [ncp.at] TRACE: < 23,0 <---- EXT correct
0000487068 [ncp.at] TRACE: < 24,255
0000487069 [ncp.at] TRACE: < 25,255
0000487070 [ncp.at] TRACE: < 42,255
0000487070 [ncp.at] TRACE: < OK

at line 808 we get the log info “Using external SIM card” as expected (matches the cloud debug trace)

at line 866 there is a checkSimCard() call, which at line 1050 does the AT+CPIN? and somewhere between line 1054 and 1063 i figure the issue is… but i can’t see where the mapping to “SIM not inserted” is being done… maybe a problem for tomorrow!

rickkas7 · April 1, 2020, 6:36pm

Does your non-working SIM card have a PIN? Even if it’s 0000 if won’t work with the Boron, which requires that the SIM have no PIN at all. That’s about where it would fail if there were a SIM PIN required, and the error message might just be wrong.

SockThief · April 1, 2020, 7:53pm

Hi @rickkas7 - thanks for clouddebug first of all and the fine documentation

i had considered that - and whilst the SIM did have a PIN (at one stage), it does not now. I’ve thrown it in an Arduino I have here and confirmed - it also works in every other device sans PIN.

int SaraNcpClient::checkSimCard() {
    auto resp = parser_.sendCommand("AT+CPIN?");
    char code[33] = {};
    int r = CHECK_PARSER(resp.scanf("+CPIN: %32[^\n]", code));
    CHECK_TRUE(r == 1, SYSTEM_ERROR_AT_RESPONSE_UNEXPECTED);
    r = CHECK_PARSER(resp.readResult());
    CHECK_TRUE(r == AtResponse::OK, SYSTEM_ERROR_AT_NOT_OK);
    if (!strcmp(code, "READY")) {
        r = parser_.execCommand("AT+CCID");
        CHECK_TRUE(r == AtResponse::OK, SYSTEM_ERROR_AT_NOT_OK);
        return 0;
    }
    return SYSTEM_ERROR_UNKNOWN;
}

that would appear (at least to me) where my problem is occuring. But searching through the Github I can’t match where the “SIM not inserted” error is coming from. Now of course I might be looking at an old code build vs new source tree.

SockThief · April 1, 2020, 7:55pm

I also just realised i never posted the trace of the failing SIM!

$ particle serial monitor
Opening serial monitor for com port: "/dev/ttyACM0"
Serial monitor opened successfully:
0000477301 [sys.power] TRACE: Battery state CHARGING -> CHARGED
0000484953 [hal] ERROR: Failed to power off modem
0000484953 [hal] ERROR: Failed to power off modem
0000485053 [hal] TRACE: Modem already on
0000485054 [hal] TRACE: Setting UART voltage translator state 1
0000486054 [ncp.at] TRACE: > AT
0000486059 [ncp.at] TRACE: < OK
0000487059 [hal] TRACE: NCP ready to accept AT commands
0000487059 [ncp.at] TRACE: > AT+UGPIOC?
0000487066 [ncp.at] TRACE: < +UGPIOC:
0000487066 [ncp.at] TRACE: < 16,255
0000487067 [ncp.at] TRACE: < 19,255
0000487068 [ncp.at] TRACE: < 23,0
0000487068 [ncp.at] TRACE: < 24,255
0000487069 [ncp.at] TRACE: < 25,255
0000487070 [ncp.at] TRACE: < 42,255
0000487070 [ncp.at] TRACE: < OK
0000487071 [ncp.at] TRACE: > AT+UGPIOR=23
0000487078 [ncp.at] TRACE: < +UGPIOR: 23,0
0000487078 [ncp.at] TRACE: < OK
0000487079 [hal] INFO: Using external Nano SIM card
0000487079 [hal] INFO: Using external Nano SIM card
0000487079 [ncp.at] TRACE: > AT+CPIN?
0000487087 [ncp.at] TRACE: < +CME ERROR: SIM not inserted
0000488087 [ncp.at] TRACE: > AT+CPIN?
0000488095 [ncp.at] TRACE: < +CME ERROR: SIM not inserted
0000489095 [ncp.at] TRACE: > AT+CPIN?
0000489103 [ncp.at] TRACE: < +CME ERROR: SIM not inserted
0000490103 [ncp.at] TRACE: > AT+CPIN?
0000490111 [ncp.at] TRACE: < +CME ERROR: SIM not inserted
0000491111 [ncp.at] TRACE: > AT+CPIN?
0000491119 [ncp.at] TRACE: < +CME ERROR: SIM not inserted
0000492119 [ncp.at] TRACE: > AT+CPIN?
0000492127 [ncp.at] TRACE: < +CME ERROR: SIM not inserted
0000493127 [ncp.at] TRACE: > AT+CPIN?
0000493135 [ncp.at] TRACE: < +CME ERROR: SIM not inserted

I can trace this, with the code, right through to the AT+CPIN? call, but that’s where I get stuck now

I need to run some tests again to ensure consistency - but as per above the traces between the two sims show completely different paths, so i assume i have messed up here somewhere! ill check the sims again

SockThief · April 1, 2020, 7:57pm

I need to run some tests again to ensure consistency - but as per above the traces between the two sims show completely different paths, so i assume i have messed up here somewhere! ill check the sims again

system · October 1, 2020, 7:57am

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Connection Issues With Activating Recent (Nov 2019) Borons Troubleshooting boron	8	648	December 11, 2019
Failing to connect Boron LTE over cellular Connectivity boron	5	573	January 7, 2021
Boron LTE not connecting Troubleshooting boron	8	1348	July 4, 2019
Boron LTE will not connect to Particle cloud using Internal Sim if an External Sim is installed Troubleshooting boron	6	715	January 28, 2019
BORON LTE is connected but could not send message Connectivity boron	7	777	November 19, 2021

Boron LTE throwing SIM not inserted error (bad HW?)

Related topics