I think the order of commands should be more like this:
[code]
gsm.rxflush
bytefill(@message, 0, 127)
debug.str (string("Get message in memory 1..."))
gsm.str (string("AT+CMGR=1")) 'Read sms in first memory
gsm.tx(13) 'CT
gsm.RxStrTime(300,@mess1) '
How can a serial operation using rxtime or rsstrtime "stop"? Do you mean the code literally locks up? I don't know where the gsm object is that you are using, post a link if possible. Does gsm.RxStrTime have a return value for success or fail? If not maybe you can modify it to return any value that indicates an error as well as successful completion. Then, do something like this to locate where the problem is happening:
Assume the gsmstrtime returns a 1 when completed
gsm.rxflush
bytefill(@message, 0, 127)
debug.str (string("Get message in memory 1..."))
gsm.str (string("AT+CMGR=1")) 'Read sms in first memory
gsm.tx(13) 'CT
if gsm.RxStrTime(300,@mess1) == 1
debug.str(string("1"))
if gsm.RxStrTime(300,@mess2) == 1
debug.str(string("2"))
if gsm.RxStrTime(300,@mess2) == 1
debug.str(string("3"))
' etc for all
This will display the last number to complete, so you can see if there is a specific location hanging.
Yeas, the code locks up!
I have tried exactly what you suggested, and it stops in different lines every time.
The gsm obj. refer to Extended_FD Serial.
Looking at some of the code you have posted earlier, there are indentation errors. Is this just my computer or do you have code written at the far left? The only words that should be on the extreme left are PUB, CON, VAR, DAT, OBJ.
If it is just a display issue and the indention is ok, can you try this:
Take a screen shot or copy/paste the response?
PUB main
debug.start (115200)
waitcnt (10_000_000 + cnt)
gsm.start (26, 27, 0, 9600)
waitcnt (10_000_000 + cnt)
dira[2] :=1
readmessage
pub readmessage | val
gsm.rxflush
bytefill(@message, 0, 127)
gsm.str (string("AT+CMGR=1")) 'Read sms in first memory
gsm.tx(13) 'CT
debug.str (string("Test1..."))
repeat 1000
val := gsm.rxtime(1)
if val <> -1
debug.str(val)
Did you run the test code above to print out the raw data received? It would be helpful to see exactly what is coming back to understand what is going on.
Is there a way to send a getstatus to the modem to see if it is busy before requesting anything?
Here come some results from the Serial Terminal:
The upper window show the result when i try your testcode. The left window show the result when i have a sms message in the modem memory, the message is "off".
The right window is when there is no sms in the modem memory.
In the cases abowe, the propeller don't stop, it just go on with the repeat loop. In the abowe cases i have sent the sms message before i start the propeller, so i am sure its not recieving it under execution of the code.
The Prop should not hang up using rxstrtime, it should just time out if it does not get any data. After you get the ERROR, you should issue the command to view the extended error with AT+CMEE=1 to have the modem respond the error code. But, what is strange is that you stated that the Prop only hangs "at different lines" up when the modem is receiving an sms. Does this mean you are sending an sms from your cell phone while sitting at the computer watching the screen.. the modem immediately starts receiving the sms from it's radio, and the Prop locks up? Is it possible that it is not the Prop locking up but rather the debug communication to the pc that is locking up? One way to test that this is a communication error to the PC is to set up some LED code to toggle the LED on/off following every debug line. So for every line of the debug you should see an LED toggle. When you get the Prop to 'lock up', are you powering off the Prop so it loads again off it's eeprom, or are you reprogramming the Prop from the PC.
The Prop can hang up for several reasons, but I do not see a reason in your code. Some examples of Prop locking:
1. ser.rx - you entered a mode to wait indefinitely for a byte
2. the stack for a cog was too small, and the stack is running over causing problems on other memory locations
3. waitpeq, waitpne, repeat while/until - an intentional wait instruction
4. the program is near the max size, it may compile and run but then crash
5. an array was declared too small and some code that wants to affect the array is actually affecting other memory locations
The "error" from the modem is because i ask for the message in storage 1, and this is empty. When this happen the RxStrTime just time out, this is my plan when the modem don't have a recieved sms. In the "on" and "off" obj i send a answer sms to show the status, this show me that the prop don't stop.
When i don't have a sms in the modem storage 1, the RxStrTime -instruction just times out, and its under this time the prop seems to hang. When this happen, i load the program into the propellers RAM again to restart it, maybee i should try to load it in the eeprom instead?
I guess I should have further asked if the program was already in the eeprom. So, for example if there is some reason the Prop is resetting, is there a program in it so when it reboots it will start again. If there is no program in eeprom, you could be seeing a Prop reset, but I do not know why that could be unless it is a power supply issue and the modem is powered off the same supply, and it is taking extra power when communicating back and forth with the cell tower?
EDIT. You have stated two different things. One says that when you get ERROR that the prop times out. The other time you said that it times out ONLY when it is busy receiving an sms. Please be more specific about what is the condition when it is timing out.
If the Prop is resetting, AND if you have a program in EEPROM, you can put some LED indicator at the top of the Program to let you know that the Prop has just reset.
PUB LEDbootInd 'turn on LED for 2 seconds on boot up
dira[2] := 1
outa[2] := 1
waitcnt(160_000_000 + cnt)
outa[2] := 0
waitcnt(160_000_000 + cnt)
Thats the answer, the prop is resetting! But why?
I have a program in the eeprom that uses a lcd display. I connected the lcd, and when the prop seems to hung, the lcd starts!
I apologize, the "error" is an answer from the modem when there is no message in storage, nothing else!
Sorry I can see no reason for the Prop to reset in the code. Since you are using a cell and and modem near the Prop, is there a chance there is noise from those devices causing the Prop or FTDI 232 chip to trip? One this to test, disconnect the USB cable to the Prop board. Run the device and see if it resets, notice the LED indicator I described earlier to see if there is a reset. If the modem is power off the same supply as the Prop it could be pulling too much of the Prop power supply. A reset on the Prop via hardware would be on the Reset pin. If the Prop power drops below a certain level it will reset. A volt meter may be able to notice the level changes if you do not have a scope. Meter the Prop supply when it is resetting, see if there is a drop out.
Maybe some others here can have a suggestion on the drop out, but you need to specify which board you have, what is connected to it, how the modem is powered.
In post 41 you show unexpected terminal output - weird characters. I'm my experience, unexpected characters and code that restarts indicates a bug, like overrunning a buffer or blasting a pointer. That is, assuming there's no hardware issue.
The upper part shows the output from a testcode, not the code im using now. The RxStrTime uses delimiter with ",", and that seems to work fine. The other two result in post 41 shows that.
Comments
[code]
gsm.rxflush
bytefill(@message, 0, 127)
debug.str (string("Get message in memory 1..."))
gsm.str (string("AT+CMGR=1")) 'Read sms in first memory
gsm.tx(13) 'CT
gsm.RxStrTime(300,@mess1) '
It's in one of the RxStrTime -lines (can be different) it stops.
Assume the gsmstrtime returns a 1 when completed
gsm.rxflush bytefill(@message, 0, 127) debug.str (string("Get message in memory 1...")) gsm.str (string("AT+CMGR=1")) 'Read sms in first memory gsm.tx(13) 'CT if gsm.RxStrTime(300,@mess1) == 1 debug.str(string("1")) if gsm.RxStrTime(300,@mess2) == 1 debug.str(string("2")) if gsm.RxStrTime(300,@mess2) == 1 debug.str(string("3")) ' etc for allThis will display the last number to complete, so you can see if there is a specific location hanging.
I have tried exactly what you suggested, and it stops in different lines every time.
The gsm obj. refer to Extended_FD Serial.
Thanks!
/Micke
If it is just a display issue and the indention is ok, can you try this:
Take a screen shot or copy/paste the response?
PUB main debug.start (115200) waitcnt (10_000_000 + cnt) gsm.start (26, 27, 0, 9600) waitcnt (10_000_000 + cnt) dira[2] :=1 readmessage pub readmessage | val gsm.rxflush bytefill(@message, 0, 127) gsm.str (string("AT+CMGR=1")) 'Read sms in first memory gsm.tx(13) 'CT debug.str (string("Test1...")) repeat 1000 val := gsm.rxtime(1) if val <> -1 debug.str(val)It would be a good idea to upload your spin file.
Here is my latest code, it works as long as the modem dont recieve a message at the same time the RxStrTime strings is executed...
Thanks again for your help!
/Micke
Is there a way to send a getstatus to the modem to see if it is busy before requesting anything?
Try changing the array lengths to 64 and test.
The upper window show the result when i try your testcode. The left window show the result when i have a sms message in the modem memory, the message is "off".
The right window is when there is no sms in the modem memory.
In the cases abowe, the propeller don't stop, it just go on with the repeat loop. In the abowe cases i have sent the sms message before i start the propeller, so i am sure its not recieving it under execution of the code.
Can the modem really get the prop to stuck?
The Prop can hang up for several reasons, but I do not see a reason in your code. Some examples of Prop locking:
1. ser.rx - you entered a mode to wait indefinitely for a byte
2. the stack for a cog was too small, and the stack is running over causing problems on other memory locations
3. waitpeq, waitpne, repeat while/until - an intentional wait instruction
4. the program is near the max size, it may compile and run but then crash
5. an array was declared too small and some code that wants to affect the array is actually affecting other memory locations
PUB Toggle outa[2] := 1 waitcnt(20_000_000) outa[2] := 0 waitcnt(20_000_000) ..................... debug.str(@mess1) debug.newline Toggle debug.str(@mess2) debug.newline Toggle etcWhen i don't have a sms in the modem storage 1, the RxStrTime -instruction just times out, and its under this time the prop seems to hang. When this happen, i load the program into the propellers RAM again to restart it, maybee i should try to load it in the eeprom instead?
EDIT. You have stated two different things. One says that when you get ERROR that the prop times out. The other time you said that it times out ONLY when it is busy receiving an sms. Please be more specific about what is the condition when it is timing out.
If the Prop is resetting, AND if you have a program in EEPROM, you can put some LED indicator at the top of the Program to let you know that the Prop has just reset.
PUB LEDbootInd 'turn on LED for 2 seconds on boot up dira[2] := 1 outa[2] := 1 waitcnt(160_000_000 + cnt) outa[2] := 0 waitcnt(160_000_000 + cnt)I have a program in the eeprom that uses a lcd display. I connected the lcd, and when the prop seems to hung, the lcd starts!
I apologize, the "error" is an answer from the modem when there is no message in storage, nothing else!
Maybe some others here can have a suggestion on the drop out, but you need to specify which board you have, what is connected to it, how the modem is powered.