Shop OBEX P1 Docs P2 Docs Learn Events
Uart hangs (even with Peter's library!) - firmware problem? — Parallax Forums

Uart hangs (even with Peter's library!) - firmware problem?

GregSGregS Posts: 15
edited 2011-03-06 17:00 in General Discussion
Hi All

I hope that you can help me-

My problem is that I have expended considerable effort (over a period of 8 months) and resources (for me anyway!) in writing software and developing hardware using a Javelin to interface to a GSM modem to do some data logging. However, whatever I try, the Javelin hangs after a variable amount of time (between 30minutes and 20hours). While working, everything is fine and the Javelin-GSM interface works as expected.

I have reduced the hardware and software to and absolute minimal test configuration, but the problem persists (the hardware is the Javelin chip interfacing to a Telit GSM modem via send and receive lines. The minimal program is attached).

In your experience, is the Javelin, particularly when using the Uart, subject to unexpected crashes? Is there a possible “race” condition in the firmware?

Amongst many options, I have tried:
Two different Javelin chips (all I can afford).
Two different GSM modems.
Various serial speeds and stop bit configs.
Well constructed hardware – ground plane, no ground loops, decoupled supply lines, various power supplies (including auto battery), shielded metal containers, shielded serial cables, etc.
GSM modem and antenna well away from Javelin.
I observe anti-static handling procedures.
Alternate Uart library (Peter Verkaik’s!).
No memory leaks (checked with Memory.freeMemory).
Even removed timers and System.out commands in case of VP conflicts.
Grounding the Atn pin to prevent spurious rebooting.
All unused pins are set to outputs.
MAX232 line drivers in case the simple resistor interface had problems.
Nothing has worked.

If anyone could identify the problem, or are aware of a problem with the Javelin/Uart hardware/firmware, I would appreciate your input.

Thanks in advance
Greg

import stamp.core.*;


public class Monitor1 {


/** VARIABLES ==============================================================*/

static Timer todTimer = new Timer();
static Uart gsmIn;
static Uart gsmOut;
static final int ledPin = CPU.pin8;
static boolean ledState = false;

/** METHODS ================================================================*/

/**
main - program starts here
*/
public static void main() {

int loopCount = 0;

// Unused pins to output/low
CPU.writePin(CPU.pin0, false);
CPU.writePin(CPU.pin1, false);
CPU.writePin(CPU.pin2, false);
CPU.writePin(CPU.pin3, false);
CPU.writePin(CPU.pin4, false);
CPU.writePin(CPU.pin5, false);
CPU.writePin(CPU.pin6, false);
CPU.writePin(CPU.pin7, false);
CPU.writePin(ledPin, false);
CPU.writePin(CPU.pin9, false);
CPU.writePin(CPU.pin10, false);
CPU.writePin(CPU.pin11, false);
CPU.writePin(CPU.pin12, false);
CPU.writePin(CPU.pin13, false);

// MAX232 interface configuration
gsmIn = new Uart(Uart.dirReceive, CPU.pin14, Uart.dontInvert, Uart.speed4800,
Uart.stop2);
gsmOut = new Uart(Uart.dirTransmit, CPU.pin15, Uart.dontInvert, Uart.speed4800,
Uart.stop2);

// Flash lights and delay for a while on bootup.
for (int i=0; i<100; i++) {
CPU.writePin(ledPin, true);
CPU.delay(500);
CPU.writePin(ledPin, false);
CPU.delay(500);
}

// Set up the modem
waitCommand("AT"); // Say hello - sync uart
waitCommand("AT+ICF=1"); // framing 8b2s0p REMEMBER UART
waitCommand("AT+IPR=4800"); // baud rate REMEMBER UART
waitCommand("AT+IFC=0,0"); // No flow control
waitCommand("ATE0"); // Echo off
waitCommand("ATQ0"); // Enable result codes
waitCommand("AT+CMGF=1"); // Text message format
waitCommand("AT+CLIP=1"); // Caller ID presented
waitCommand("AT+CNMI=2,2,0,0"); // New message - buffer and send
// waitCommand("AT+CMGD=1,4"); // Delete ALL messages



// .........................................................................
// Main processing loop
todTimer.mark();
while (true) {

// Read any input from modem and display
int c;
if (gsmIn.byteAvailable()) {
c = gsmIn.receiveByte();
//System.out.print((char)c);
}

// Every minute process timer
if (todTimer.timeoutSec(60)) { // every minute
todTimer.mark();
sendCommand("AT+CCLK?"); // get the time
//System.out.println(Memory.freeMemory());
}


// Flash led
loopCount = loopCount + 1;
if (loopCount > 100) {
loopCount = 0;
CPU.writePin(ledPin, ledState);
ledState = !ledState;
}

} // while main loop


} // main


/** ..........................................................................
sendCommand - send without waiting
*/
private static void sendCommand(String cmd) {
CPU.writePin(ledPin, ledState);
ledState = !ledState;
gsmOut.sendString(cmd);
gsmOut.sendByte(0x0d);
} // .sendCommand


/** ..........................................................................
waitCommand - send command and wait for X sec, discard any input received
*/
private static void waitCommand(String cmd) {
CPU.writePin(ledPin, ledState);
ledState = !ledState;
gsmOut.sendString(cmd);
gsmOut.sendByte(0x0d);
for (int i=0; i<1000; i++) {
if (gsmIn.byteAvailable()) {
gsmIn.receiveByte();
}
CPU.delay(10);
}
} // .waitCommand

} // class Monitor1

Comments

  • jmspaggijmspaggi Posts: 629
    edited 2011-03-03 06:48
    Hi Greg,

    My Javelin is doing everything at home.

    It's connected to a display using UART (writeonly), connected to a solar controller using UART (readonly+maxx485), connected to DC16s (writeonly) and connected to my computer (writeonly).

    And it's running days after days after days.

    My code is way bigger than the sample below.

    I read you sample and I'm not able to find anything wrong. That's what's surprising me. The only thing I notice is that sometime Javelin don't like the while (true) loops. Maybe you can define a boolean and do a while (myBoolean) instead. I know it's useless, but I figured that sometime.

    Also, I have tried to debug you code with the Javelin debugger to see if there is any memory leak anywhere?

    JM
  • GregSGregS Posts: 15
    edited 2011-03-03 21:46
    Thanks JM

    I have found that when I include debug or System.out.println that the program never crashes! I currently believe that the problem may be in the Uart.java receiveByte code. There MAY be a timing problem when the hardware/firmware uart is updating the nmUartHead/Tail pointer at the SAME TIME as Uart.receiveByte is updating these pointers. I am not sure how the Virtual Peripherals are scheduled so I can't be absolutely sure.

    When I comment out the send/receive code in the sample program, the code runs forever. Also it seems not to be a memory leak (see the commented-out System.out.println).

    The problem also SEEMS worse when I use a low baud rate, which also points to a probable timing problem in Uart.receiveByte - there is more chance of an overlap of data arriving and the program waiting/testing for data. Again, looking at the Uart.sendByte code, the problem COULD also occur there!

    The problem also occurs MUCH sooner with the test program above than in my final application - also possibly because in the short program, the code spends far more time overlapping the arrival of data with the extraction from the Uart buffer.

    The problem also SEEMS to take longer to occur using Peter Verkaik's modified Uart library - possibly because he has less code between reading the nmUart pointers and writing them back.

    All of this is speculation, and I hope for input from Javelin users far more experienced than me.

    Thanks for your input.
    Greg
  • jmspaggijmspaggi Posts: 629
    edited 2011-03-04 13:31
    I just tought about something...

    Can it be the modem which is hanging?

    If that's the case, the output UART buffer will be full, and then you will get out of sendCommand("AT+CCLK?")?

    When your javelin is locked, can you try to reset the modem only and see if it's changing something?

    Also, can you add logs to see exactly where it's stuck?

    JM
  • GregSGregS Posts: 15
    edited 2011-03-05 07:44
    Hi JM

    I've now tried adding ferrite beads to the signal lines to the modem and this seems to improve the situation. I am now going to re-layout the PCB to isolate and filter the modem comms. It might be that RF/interference is being injected here from the modem, despite the MAX232. (RF and PCB layout are not my strong point).

    My appologies to Peter and Parallax for doubting their code - it is likely to be my own stupidity, the place I should have started looking first!

    Thanks for the input.
    Greg
  • jmspaggijmspaggi Posts: 629
    edited 2011-03-06 17:00
    No Worries for Peter and Parallax :p I don't think they are ready those threads anymore ;)

    Good luck with your PCB and your propeller.

    JM
Sign In or Register to comment.