UART stutters on startup

[Miq1]

[I am hoping I will not get permanently banned again, as it has happened twice before... ]

I am using the Cell with an Arduino MKR1000, connected to hardware Serial2. As soon as the UART communication starts working, all is fine, but the initial startup has an issue.

After resetting/powering the Arduino, a 100ms LOW signal is put to PO. Hence the Cell restarts and is able to establish a 3G connection, as I can see from the LED.

But serial communications on the UART is possible only once in a while - it may work immediately after power up, may take several seconds to minutes to finally get up or never start at all. I see all three schemes repeatedly, with the comms failing more often.

Serial speed was set to Auto (+ZBITRATE=1, then +ZBITRATE=S), with the Arduino communicating at 9600 baud at the moment.

It is not reliable enough for me to use, so what would you suggest doing?

[donjohnii]

Typically I would go through a loop to not use a product until consistent communication was established... so something like:

flag_go=false
1. Check if ate1 returns 'ok', if so flag_go=true, if not flag_go=false
2. check for 'ok' and wait 10sec interval for 120sec total, if good flag_go=true, if not flag_go=false
3. if previous check failed, reset connection and restart check

Unless the HW is busted, which isn't your problem, the above look should establish a consistent connection. It's a very common scenario with interconnecting and working with HW that the connection takes a couple tries and there needs to be a retry and wait mechanism in order to establish a consistent connection.

[u063096]

What time to wait for the connection would you suggest then? I currently have a loop iterating through the baud rates and sending AT only, then wait for the OK, but that seemingly works only once in a while. I could not find a pattern yet as when the communication will establish or not.

[donjohnii]

I wouldnt suggest changing the baud as that will cause errors too. Stick with a 1m-3m loop on reset.

If you are having these type of consistent issues, it's not common. You probably have a bad modem or driving with a bad baud.

[Miq1]

I cannot get it up....

Basically I power up the system, then select the baud rate for the UART on the MCU side (38400, as I was able once to set it permanently with +ZBITRATE=S), then pull PO to LOW and up again to init the Cell. After some seconds, the 3G LED goes on.

But regardless how often I will send the ATE1<CR> with 10s pauses in between, I almost never will get a response. Once I get an "OK", it will work until the next power down.

Interestingly, if I will send ATE1 with 19200 bauds several times, then switch to 38400, and send ATE1 again, this will result in an "OK" response half of the time. Strange...

Code: Select all

Baudrate: 19200
.....ATE1 sent at 19200 Baud.
.....ATE1 sent at 19200 Baud.
.....ATE1 sent at 19200 Baud.
.....ATE1 sent at 19200 Baud.
.....ATE1 sent at 19200 Baud.
.....ATE1 sent at 19200 Baud.
.....ATE1 sent at 19200 Baud.
.....ATE1 sent at 19200 Baud.
Baudrate: 38400
.....ATE1 sent at 38400 Baud.
ATE1

OK
.....ATE1 sent at 38400 Baud.
ATE1

OK


I can positively attribute the effect to my UART handling, as two identical systems with two different Cells are behaving identically. But where is my fault?

[donjohnii]

This suggestion is probably not awesome, but I would stick with the default baud rate. If you've changed the baud rate but are still seeing the original, then either it's not initializing soon enough or it's potentially getting misaligned somehow due to the baud rate issue. So utilizing the default baud would eliminate that issue.

It does seem like there's some type of overflow situation or even a sleep situation that is causing the modem to not come back.

Someone else is currently asking about sleep/hang and your issue could be similar. To eliminate potential causes, I'd suggest to do 2 things at this point - use the default baud and check the sleep status using the below information:

There are a couple of things to try to debug based on the 5 status I/O lines. If you look at the datasheet, the 5 lines are for:

2 Main Lines
PRN - reset's the board
PO - controls on/off functionality

5 Status lines:
AR (input) - Module (CELLv1.0) checks if AP is asleep
MR (output) - Module sleep status... If it's asleep, this will be lit
AWM (input) -
MWA (output)- Module (CELLv1.0) wakes up AP (Client)
MP (output) - Module Poweron indication

I don't use these status lines much, but it's possible I have them connected in a certain way in my tests that I cause it to stay on. So I would suggest that you provide:
-AR 0V to tell the module that the the client is available
-AWM 0V to tell the module to wakeup if it is sleeping

Then check the status lights of:
-MR to make sure it's dark (LED off) indicating it's awake
-MWA should be lit (LED on) to indicate that the module is telling the AP to be awake
-MP should always be lit (LED on) indicating power to the module

[Miq1]

Thanks for the advice. I already tested with AR and/or AWM set to GND unfortunately with no different results. Remains the check of the info lines; I will need a multimeter or osc to check tomorrow, as the Cell is on a PCB already and not easily rewired.

I can confirm the odd "send ATE1 9-12 times on 19200, then switch to 38400" method works almost every time I try it. So the Cell seems to be listening in general, but I somehow do not get the data right.

[donjohnii]

I can positively attribute the effect to my UART handling, as two identical systems with two different Cells are behaving identically. But where is my fault?

I missed this comment - so you're saying you're seeing the same effect on two CELLv1.0s with the same code when you're manipulating the baud rate? That's good that it's consistent actually... means your HW is good.

Thanks for the advice. I already tested with AR and/or AWM set to GND unfortunately with no different results. Remains the check of the info lines; I will need a multimeter or osc to check tomorrow, as the Cell is on a PCB already and not easily rewired.

Great debug steps... so it's not sleeping. It's getting caught somewhere in the switchover.

Have you setup a simple echo device - write from the Arduino IDE through Serial0, print to CELLv1.0, echo results to Serial1? I'm not sure about your code, but getting consistency on an earlier, simple codebase and moving up from there is the way to go.

Debugging when dealing with the rest of the code is a bit of a pain as you don't really know where the error came into play. I would suggest loading this simple echo test and getting consistency on it before moving forward.

I can confirm the odd "send ATE1 9-12 times on 19200, then switch to 38400" method works almost every time I try it. So the Cell seems to be listening in general, but I somehow do not get the data right.

I'm a little confused by this statement... you said it works almost every time. So what is the problem then? Not getting the "OK" after switching the baud?

I'd suggest not switching the baud as a quick test/fix... you're not going to be able to utilize the additional baud rate on an Arduino anyhow. And if your program runs fine without switching, that could point to a clock inconsistency/offset between the two devices. Depending on what clock sources both devices are using, different baud rates act and line up differently with eachother.

[Miq1]

Great debug steps... so it's not sleeping. It's getting caught somewhere in the switchover.

Have you setup a simple echo device - write from the Arduino IDE through Serial0, print to CELLv1.0, echo results to Serial1? I'm not sure about your code, but getting consistency on an earlier, simple codebase and moving up from there is the way to go.

That is exactly what I am doing to debug, the main loop() consists of a few statements only, most of it inactive unless I type in special characters:

Code: Select all

void loop()
{
  static int bauds[] = { 9600, 19200, 38400, 57600, 115200, 0 };
  static uint8_t myBaud = 1;
  static long t0 = millis()+10000;
  char myChar;
 
  if(Serial.available())
  {
    myChar = (char)Serial.read();
    if(myChar=='&')
    {
      myBaud++;
      if(!bauds[myBaud]) myBaud = 0;
       CellOne.begin(bauds[myBaud]);
    }
    else if(myChar=='#') CellOne.write(0x1a);
    else if(myChar=='!') CellOneReset();
    else CellOne.print(myChar);
  }
  while(CellOne.available())
  {
    myChar = (char)CellOne.read();
    Serial.print(myChar);
  }
  if(millis()>t0)
  {
    CellOne.print("ATE1\r");
    t0 = millis() + 10000;
  }
}


I can confirm the odd "send ATE1 9-12 times on 19200, then switch to 38400" method works almost every time I try it. So the Cell seems to be listening in general, but I somehow do not get the data right.

I'm a little confused by this statement... you said it works almost every time. So what is the problem then? Not getting the "OK" after switching the baud?

No, the baud switch is just a way to get the Cell's attention. I do not get any reaction on the "ATE1" commands with the right baud rate of 38400, unless I will apply the awkward method. As I wrote: I know the "ATE1"s at 19200 baud make no sense at all, but as I observed the Cell to work at least after having seen 8-10 of those and a subsequent switch to 38400 baud on the Arduino side I chose to dig further into that.

I'd suggest not switching the baud as a quick test/fix... you're not going to be able to utilize the additional baud rate on an Arduino anyhow. And if your program runs fine without switching, that could point to a clock inconsistency/offset between the two devices. Depending on what clock sources both devices are using, different baud rates act and line up differently with eachother.

Can you explain what you have in mind with that? I understand the bit with the clock differences, although I would assume that two UARTs running at the same nominal baud rate should be able to compensate for minor differences anyway.

But what do you mean with "you're not going to be able to utilize the additional baud rate on an Arduino anyhow"?

[Miq1]

5 Status lines:
AR (input) - Module (CELLv1.0) checks if AP is asleep
MR (output) - Module sleep status... If it's asleep, this will be lit
AWM (input) -
MWA (output)- Module (CELLv1.0) wakes up AP (Client)
MP (output) - Module Poweron indication

Now we seem to be getting further: all three MWA, MP and MR(!) lines are on HIGH level. I would not bother about MWA and MP, but MR? So it looks like the module is in sleep state after power on - but why?

Next, if I pull AWM to LOW, MR stays HIGH - what??? Even if I apply my workaround procedure and get the communication running, MR still remains on HIGH. The only thing I can imagine is that the Cell only checks the AWM line infrequently or at startup only to terminate sleep state.

I will change my wiring to connect both AR and AWM to GND, so supposedly the Cell should never feel tempted to enter sleep state.