Greetings,
Trying to debug an LTE M1 connection, I finally gave up on my own efforts and got down to basics, running the cellular unit tests included in device-os.
By doing a
make PLATFORM=boron TEST=hal/cellular
I got a serial terminal and ran the unit tests–fails on first test (terminal output pasted below) after a number of seconds (presumably times out).
This is true on two modules, with or without SIM card inserted, with external LiPo battery or just powered through USB.
LED goes solid green at start of tests and stays that way.
How do I troubleshoot the SARA modem? Should it be responding to these unit tests like this? Any ideas what the problem is?
Terminal output:
Commands:
i <glob>: include tests matching the glob
e <glob>: exclude tests matching the glob
I: include all tests
E: exclude all tests
c: count the tests
l: list the tests
t: start the tests
h: get help. It looks a lot like what you're seeing now.
So...what'll it be, friend?
Current tests included:
AT_CMD_01_set_and_read_command
AT_CMD_02_plus
AT_CMD_03_unknown
AT_CMD_04_error_test
AT_CMD_05_no_carrier
5 test(s) included.
Running tests
Assertion failed: (send_cellular_command([](int type, const char* buf, int len, int* lines) -> int { at_resp_info_print(type, buf, len, lines); if (!Test::assertion<typeof((int)TYPE_OK)>(("tests/hal/cellular/test_cellular_command.cpp"),88,("type"),(type),("=="),isEqual,("(int)TYPE_OK"),((int)TYPE_OK))) while(1);; return WAIT; }, &lines, 5000, "AT+CMEE=2\r\n")=-1) == ((int)RESP_OK=-2), file tests/hal/cellular/test_cellular_command.cpp, line 88.
Update and Question
I attempted hacking device-os to get my hands on a particle::SerialStream pointing straight to HAL_USART_SERIAL2 so I could bypass all that Cellular.command() stuff and see whether its modem or upper layers, but it was a major pain because of linking failures, so I gave up.
I tried to use the simple AT Pass thru program to see what the modem has to say. Nothing but timeouts. The modem seems to be dead but I can’t tell if it’s the modem or something in an upper layer–but the problem is present on at least two modules, now, that have worked fine in the past.
Is there a way to get access to that serial port, from user space, and drop all the fanciness just so I can know whether the SARA is alive?
Hi there @psychogenic ,
If I’m understanding correctly, you’re trying to debug some connection difficulties with your Boron LTE, correct?
I appreciate the level of depth you have going on here, but we generally do not recommend using these types of tests and diagnostics in this fashion.
I would actually recommend making use of Boron Cloud Debug. Boron Cloud Debug is a tool written by one of Particle’s staff to help debug connectivity issues such as this. You can find the included binaries and documentation on how to use the tool here at https://github.com/rickkas7/boron-clouddebug
I recommend running against v1.3.1-rc.1 and providing the debug logs here so that we can take a look at what might be going on.
1 Like
I wouldn’t mind but these devices aren’t using the cloud, normally, and half have their barcode rubbed off. I just associated the one I have with a visible a code and it SOSed me during the update (0% done). Finally, they all spew out:
Your device id is undefined
Your system firmware version is undefined
when trying to identify, making claiming them rather tough.
Is there no way to simply get ahold of the Serial stream to the modem? It is wholly unresponsive, using the Cellular.command() stuff, and I’d like to know if it’s the modem hardware or something in the upper layers.
So, rather than muck with the cloud, I managed to get it up and running locally. Increased debug to TRACE and enabled it right away, otherwise unchanged.
In short, a lot of failed waitAtResponse(), timing out, resulting in a bunch of “No response from NCP” messages. Happens with and without external SIM (which was just tested in a Pycom/Sequans Monarch LTE modem and works).
Gives me little more info, really:
or tap the MODE button once to show carriers
starting tests...
turning cellular on...
0000032870 [hal] ERROR: No response from NCP
0000032870 [hal] ERROR: No response from NCP
deviceID=e00fce68e688xxxxxxxxxxxxx
manufacturer=
model=
firmware version=
ordering code=
IMEI=
IMSI=
ICCID=
attempting to connect to the cellular network...
0000135023 [hal] ERROR: No response from NCP
0000135023 [hal] ERROR: No response from NCP
0000167274 [hal] ERROR: No response from NCP
0000167274 [hal] ERROR: No response from NCP
0000199525 [hal] ERROR: No response from NCP
0000199525 [hal] ERROR: No response from NCP
0000231776 [hal] ERROR: No response from NCP
0000231776 [hal] ERROR: No response from NCP
Got the online boron-clouddebug-v1.3.1-rc.1.bin running, too. It has a bit more info, similar results
0000110308 [app] INFO: enabling trace logging
0000110309 [ncp.at] TRACE: > AT+CGDCONT?
0000120310 [ncp.at] TRACE: > AT+CSQ
0000122469 [sys.power] TRACE: re-enabling charging
0000122497 [sys.power] TRACE: Battery state UNKNOWN -> CHARGED
0000123371 [sys.power] TRACE: Battery state CHARGED -> DISCONNECTED
attempting to connect to the cellular network...
0000130312 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000130312 [system.nm] INFO: State changed: IFACE_DOWN -> IFACE_REQUEST_UP
0000130315 [hal] TRACE: PPP netif -> 8
0000130315 [net.ifapi] INFO: Netif pp3 state UP
0000130315 [net.ifapi] INFO: Netif pp3 state UP
0000130317 [hal] TRACE: Powering modem on
0000130317 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000130317 [system.nm] INFO: State changed: IFACE_REQUEST_UP -> IFACE_UP
0000130467 [hal] TRACE: Modem powered on
0000130469 [hal] TRACE: Setting UART voltage translator state 1
0000131470 [ncp.at] TRACE: > AT
0000132470 [ncp.at] TRACE: > AT
0000133470 [ncp.at] TRACE: > AT
0000134470 [ncp.at] TRACE: > AT
0000135470 [ncp.at] TRACE: > AT
0000136470 [ncp.at] TRACE: > AT
0000137470 [ncp.at] TRACE: > AT
0000138470 [ncp.at] TRACE: > AT
0000139470 [ncp.at] TRACE: > AT
0000140470 [ncp.at] TRACE: > AT
0000141470 [ncp.at] TRACE: > AT
0000142470 [ncp.at] TRACE: > AT
0000143470 [ncp.at] TRACE: > AT
0000144470 [ncp.at] TRACE: > AT
0000145470 [ncp.at] TRACE: > AT
0000146470 [ncp.at] TRACE: > AT
0000147470 [ncp.at] TRACE: > AT
0000148470 [ncp.at] TRACE: > AT
0000149470 [ncp.at] TRACE: > AT
0000150470 [ncp.at] TRACE: > AT
0000151470 [hal] ERROR: No response from NCP
0000151470 [hal] ERROR: No response from NCP
0000151471 [hal] TRACE: Setting UART voltage translator state 0
0000151472 [hal] TRACE: Hard resetting the modem
0000162472 [net.pppncp] TRACE: Failed to initialize ublox NCP client: -210
0000162473 [hal] TRACE: Setting UART voltage translator state 0
0000162474 [hal] TRACE: Modem already off
0000162574 [hal] TRACE: Powering modem on
0000162724 [hal] TRACE: Modem powered on
0000162726 [hal] TRACE: Setting UART voltage translator state 1
0000163726 [ncp.at] TRACE: > AT
0000164726 [ncp.at] TRACE: > AT
0000165726 [ncp.at] TRACE: > AT
0000166726 [ncp.at] TRACE: > AT
0000167726 [ncp.at] TRACE: > AT
etc.
Hi @psychogenic,
There does appear to be issues communicating with the ublox module. Please file a ticket at https://support.particle.io referencing this topic. Thanks.
Hello @mstanley
I was a bit unclear on where to post the ticket–I used the “Do you have a different question?” form, but let me know if there’s an actual ticketing system I can access.
Thanks!
Hi @psychogenic
Apologies on the portal. We are working on revamping it to better help facilitate customer issues.
Feel free to pick one you think is a best fit. It should not affect how the ticket is handled. Thanks.