I experienced the sometimes the response handler of adl_atCmdCreate() function don’t get the answer. It made me hard time for example with (AT+CREG, AT+WMFM,AT+CGATT)
I also don’t understand the at+wind message. I have seen in an old document the the IP stack set to x parameter.(in os 6.41 the module forgot the setup even without open at) I saw some improvemnets but with os 6.51 everthing is back again. I have not seen in the docs that do not change the wind indicator parameters. The situation is the same
with the AT+CREG message the unsolicited messages are always coming.
Maybe this problems related to each other on some level?
I don’t recognize the problems you have with the adl_atCmdCreate() function…
But I know that its not recommended to change the value of some commands (eg. +CREG, +CGREG, +WIND…)
The ADL lib needs those AT commands in a known state in order to manage some internal configuration and the ADL lib always configure (at initialization phase, I assume) those commands internally to a fixed value.
Please also refer to §2.9 on page 15 in the “Open AT ADL User Guide for Open AT 3.02” document.
Hi tomalex,
There should not be any problem relating to the response not being captured in the response handler for the command created using adl_atCmdCreate () API. Please ensure that you have specified the correct response handler and the command is created by specifying a “*” for the variable list (which represents the responses to be subscribed).
I have not experienced the problem when the response to the command created using adl_atCmdCreate () API is not received in the command handler. All the responses to the created command will be received in the command handler until a terminal response (for e.g. “OK”) is received.
If your command is such that it sends a response after sending a terminal response too, that response will not be received in the command handler.
For instance, let us assume that you have a SIM which fails (+CME ERROR :13) when you try to write to a particular location in it. To check this scenario, you create AT+CPBW command from within your Open-AT application and subscribe to all the responses (hoping to get a +CME ERROR: 13 response too when the SIM fails).
As you know, that response to the AT+CPBW command will be an immediate “OK”. THe actual write will be performed after some time. In other words, a terminal response (“OK”) is received before receiving a +CME ERROR: 13 response. However, a +CME ERROR : 13 will not be received by the Open- AT application. This is because, once you get a terminal response (e.g. OK), the response handler for the command is deregistered by ADL and it does not receives any more responses.
However, if the problem faced by you is not similar to this, then you should check the code where you are creating the command.
I think that must be the place where some error has creeped.
For a while everything was ok, all the responses was received by the handler, but after a time no responses were received any more. (The modem didn’t crash, everthing seemed normal)
I don’t temper with the message indicator parameter (AT+WIND).
Maybe a +CREG: unsolicited response arrived when AT+CREG? response handler became “deaf” or maybe i should subscribe to only a specific response?
Hi tomalex,
I could not find any problem by executing an application which had the code as specified by you.
In order to solve the problem, you should check what other operation your application is doing. To find the cause of problem, you should try to comment other functions performed by your application and move towards the point where only the adl_atCmdCreate () API and the timer (used to create this command) remains. This might help you to figure out if any other operation is causing the adl_atCmdCreate () API to work incorrectly.
HAPPY NEW YEAR TO YOU AND ALL THE OPEN AT FORUM MEMBERS.
Best Regards.
When you don’t receive responses on AT+CREG? anymore, are you sure that other handler functions are called with answers to other AT commands (are you sending other commands where you get responses?) - or is the modem maybe in a state that actually no AT command handler will be called at all? I have seen that before…
I assume that you are starting a GPRS session, right?
Thanks for the answers. I think i am near to the solution. When i checked it in DEBUG mode i didn’t wait for the +WIND: 4 message (modem is ready to process all AT commands).
I think that caused the false working of adl_atCmdCreate() function.
To complicate things, when i start the application in DEBUG mode i see unsolicited messages coming before my DEBUG applicatiopn start.
And if i don’t stop the appli with stop and quit in RTM, the next time the appli start a little later and miss the +WIND: 4 indication, but the appli seems to start properly.
In target mode everything ok (except +CGEV: CLASS X), but what guarantees that all important unsolicited messages (moreover if i suspend the application ) will be received by the Open At application?
Is there an AT command or something else to inform the appli about all state of the module related to unsolicited messages? I haven’t seen it…
as far as I know you can’t do anything about missing some WIND indications (or maybe others, too - if they appear too quickly after reset of the module) at start of the embedded application when you are using RTE. This seems to be a feature of Open AT 3.x with the corresponding core software… The application starts with some delay and doesn’t get the very early indications.
You only do receive all indications guaranteed when in target mode. I have noticed that, too… I just searched the FAQ, but didn’t find anything official for this problem, but I think it is quite well-known and I think I have read something on this before - but I can’t remember where…
