AT Commands (reading sms/AT+CMGR) memory leak?

Troubleshooting
1

Hi,

I’m using a 2G Electron with a third-party SIM and flashed with the 0.5.2 firmware.

I’m trying to read an SMS from the cellular module like this:

#include "TestSms.h"
#include "application.h"

STARTUP(cellular_credentials_set("my.apn", "", "", NULL));

int theCallback(int type, const char* buf, int len, int* param) {
  Serial.printlnf("type: %d. buf: %s. len: %d. param: %d.", type, buf, len, (*param));
  delay(100);

  if (type != TYPE_OK) {
    return WAIT;
  }
  else {
    return RESP_OK;
  }
}

void setup() {
  Serial.begin(9600);
  while(!Serial.available()) {
    Particle.process();
  }
  Serial.println("Serial started.");

  int a = 5, resp;
  Serial.println("Before.");
  resp = Cellular.command(theCallback, &a, 300000, "AT+CMGF=1\r");
  delay(100);
  Serial.printlnf("After. Resp: %d.", resp);

  Serial.println("Before.");
  resp = Cellular.command(theCallback, &a, 300000, "AT+CPMS=\"MT\"\r");
  delay(100);
  Serial.printlnf("After. Resp: %d.", resp);
}

void loop() {
  delay(10000);
  int a = 5, resp;

  Serial.println("Before.");
  resp = Cellular.command(theCallback, &a, 300000, "AT+CMGR=1\r");
  delay(100);
  Serial.printlnf("After. Resp: %d.", resp);

  if (resp != RESP_OK) {
    Serial.println("Not ok.");
  }
  else {
    Serial.println("Ok.");
  }
}

The responses I get from the cellular module are strange. Here’s a picture (since I can’t copy-paste from the serial monitor):

Capture.PNG415×535 12 KB

The AT Commands Examples Manual (page 110) says that the response for “AT+CMGF=1” should be “OK” but I get something like "OK\r\n , ".
Also, as you can see, my biggest problem is with retrieving the contents of an SMS. After I call “AT+CMGR=1” I get three responses:

  1. One with a type of TYPE_PLUS that contains just the SMS headers and lots of gibberish. The weird thing is that the “len” callback parameter says that the response length is 53 which is exactly the length of the message except for the gibberish part.
  2. One with a type of TYPE_UNKNOWN that contains the SMS text (“Test. Test. Test.”) then a part of the SMS headers then the (same) gibberish again. The “len” parameter, again, only acknowledges the good parts of the response. The TYPE_UNKNOWN status if very disturbing.
  3. One with a type of TYPE_OK that contains part of the SMS text, part of the SMS headers then the dreaded gibberish.

This smells a lot like a memory leak but I can’t really figure out if I did something wrong and what that would be.

As a side question: I tested the same code with “\r” and “\r\n” at the end of the AT commands I sent. The result is the same but I wonder, which one is correct?

Thank you!

2

I'd say the gibberish comes from the fact that the message is not a C string but the message only.
In order to "convert" that into a valid C string you need to add the terminating '\0' after the last character of the message at buf[len].

And the docs are specific about the "\r\n" too
https://docs.particle.io/reference/firmware/electron/#command-

And the responses do obey the same rule.

3

@ScruffR: Thank you very much for the quick reply! Sorry for the “\r\n”, I missed that part.
Ok, so I’ll parse the message only based on the “len” parameter but what about that intermediary response with TYPE_UNKNOWN? How should I handle that? When should I expect it?

4

I’m not exactly sure why this is a TYPE_UNKNOWN and not a TYPE_TEXT, but that seems to be how the module returns SMS text.
This might be something to look into the ublox docs.