I have currently written a simple ADL-based application which simply prints an unsolicited AT response when my Fastrack M1306B receives an SMS message.
The application itself, when first started, runs fine, except that every 12-16 hours the application stops calling the SMS event handler I’ve subscribed and reverts to its default behavour of saving the SMSs in memory. Once restarted with (at+wopen=0 then at+wopen=1) everything returns to normal.
I then tried creating a ADL_timer event that prints out an unsolicited AT response every 60 seconds to see if it was just the SMS handler or the entire application, and the timer event stops as well.
When the program stops, there is no WIND-style indication to say that my application has crashed or stopped running - it just seems to give up without any warning. Has anyone else had this problem? Does anyone know what might be causing it or how to fix it? ATI3 returns “657_09gg.Q2406B 1954500 102706 18:44”
I have never experienced any problem like that.
Please make sure that your application is not crashing while executing for 12-16 hours.
This is because, if you have a code something like:
void adl_main(adl_InitType_e Init)
{
if (Init ==ADL_INIT_REBOOT_FROM_EXCEPTION)
{
//don’t do anything
}
else
{
//perform the application logic
}
}
So, in this case, if the application fails in between, the normal operation would never be reverted back. You can enable the RTK level 1 trace to find out if any exception is occuring.
Normally, if the application crashes out after a long time, it can be attributed to some memory leakage.
Also, check the power supply. Is it providing the requisite amount to the Wireless CPU? I am not sure whether checking the power supply would help, but it might be one of the thing that can be checked.
I don’t differentiate between the different start up types at the moment, so even if an exception caused a restart, the re-initialisation would still occur.
It’s definately not memory leakage - I’m not using any dynamic / heap memory, just variables either on the stack or declared globally. Currently all the application does is pring as adl_atSendResponse(ADL_AT_UNS, …) the phone number, timestamp and message that comes into an SMS handler (if the message is entirely ASCII)
Yep - the power supply is OK.
I’m definately checking for restarts and so forth - they never occur when this failure happens. The program simply stops printing out SMS messages without warning. Also, I tried using the FCM support to remove the AT interaction, and the SMS handler still de-registers, but the timer continues to function normally.
If the timer continues to run, it means that the Open AT is still running but the problem is in printing out the SMS message.
Did you try to use adl_atSendResponse () API with ADL_AT_RSP (instead of ADL_AT_UNS)? This is because, sometimes, the unsolicited responses are bufered until a final response is not sent. I am not sure but you can give it a try.
You can use ADL_AT_RSP in the adl_atSendResponse () and then check out the application. You can also put traces in the application and check if the traces come when the SMS is received.
I haven’t tried using ADL_AT_RSP - in the FCM version of the application (which doesn’t work reliably either), I use adl_fcm_sendData() functions, bypassing the AT stuff.
Also, the SMSs which are skipped make their way into SIM card memory (like as if all of the SMS handlers returned TRUE), so the application isn’t “freezing” or “blocking” like you’d expect for something that is waiting for a buffer to fill up.
I’ll give it a go - thanks for your suggestion. (Any other readers of this thread, please continue to provide suggestions!)
Please confirm that you are not receiving an SMS which is having a value 2 for Data Coding Scheme and Sim Data Download for Protocol Identifier.
This is because, according to 3GPP specs, an SMS having the above mentioned values is stored directly to the SIM card and is not displayed to the user. This might be one of the reason why the SMS is not being displayed in the handler.
Another thing that you can check is to enable the ATI Level 1 traces and check out what commands are issued when an SMS is received. The reception of a normal SMS would show you a +CMTI indication. Then you should see AT+CMGR command which is issued by ADL library to read the SMS. If AT+CMGR command is not issued (but +CMTI indication is received), it means that the ADL library is not reading the SMS and there is a problem in ADL. However, if +CMTI is also not received, then the case of Data Coding Scheme and Protocol Identifier might come into picture.
Just to let you know that I tried your ADL_AT_RSP suggestion, and the application has now gone more than 24 hours without falling over, which is a record so far. Hopefully this means that the issue is fixed (I’ll open a new “part 2” thread if it isn’t). I haven’t worked out yet why it’s happening in FCM mode, but I suspect that might be due to the fact that data going into the fcm_sendData function needs to be allocated on the heap. Wavecom’s documentation in these areas isn’t very clear about these things.
With regards to the SMS classification, without going through the PDU, I’m pretty sure it isn’t, since I’m just writing normal SMS messages using my own mobile phone. Also, if they were being flagged like you’ve suggested, then wouldn’t the problem be occurring from time=0?