Here is a scenario that is being used in my OpenAT application. The inablility to get an indication of the state of the ON/OFF pin 19 can lead to placing the modem OS in a state such as described below.
Changing the state of the pin does not cause the modem to power off. (ref page 50 in the Q2686 Product Technical Specification) The AT+CPOF command initiates the power off procedure. In our usage, code is written that controls pin 19 externally using an fpga. Actually the command to bring that pin low is issued by software that is talking to one fpga module on one piece hardware. That fpga talks to a second fpga that is in an antenna farm where the modem resides. We are working on a problem (not the modem’s at this point) where the modem gets into a solid indicator state and needs to be hard reset to get going again. I can produce the state by issuing the AT+CPOF command to the modem on my dev board and not turning off the ON/OFF switch controlling pin 19. The engineers here are testing to make sure that PIN 19 is kept low when the command to do so is issued.
The issue comes down to this. There is a serial packet command that the controlling firmware issues to the OBA to issue the AT+CPOF command. The serial command is sent after a delay of ~500 msec following the deactivation of pin 19. Varying delays have been used with intermittant results. When the serial command is issued, the connection status for a PDP context is checked. If the modem is ‘on line’, A disconnect is performed, then the CPOF command is issued. If pin 19 is not low when the command is issued, the OBA remains operating, the network connection will be disconnected, the LED goes solid color and reconnection to the network cannot be accomplished. The OBA is still functioning normally on the serial port. As I said previously, when the LED goes to solid on, a hard reset is the only way out of this state. If for some reason the pin is not low at the time the OBA receives the command to issue AT+CPOF, the command should not be issued. Target monitoring tool traces confirm all of the about actions. I might add that the software module issiung the serial command to shut down the modem CPU has no way of making sure pin 19 is indeed set low before the command is issued.
To prevent this type of ‘failure’, I believe the capability of determining the state of PIN 19 within the OpenAT environment is essential. A suggested way to do this would be an OS unsolicited event each time PIN 19 has a transistion. Providing this to the OBA allows an OBA to track PIN 19 state and only issue the AT+CPOF command if the state of PIN 19 is low.
I was waiting if someone else answers but it seems they are as confused as I am.
What is your problem, exactly? Why is AT+CFUN=1 not good enough? It restarts the module, regardless the state of the ON/~OFF pin.
There’s also a RST pin, or you can power-cycle the module.
If you turn off the module via AT+CPOF with ON/~OFF down, who restarts it? An external processor? Can the module ask for confirmation before issuing AT+CPOF?
You cannot read the ON/~OFF pin, and that’s it. Either connect it to a GPIO, or make the external circuit more reliable/more clever.
Answer to Question 5: The OBA (On Board Application) is the OpenAT embedded application residing in the modem application space.
This application is NOT an AT Command interface, but a DATA mode serial packet interface. It does not allow the use of AT commands. All controls are via a defined serial packet interface. Answer to Question 2: The reset pin is being used for the purpose of recycling power if needed. It is NOT used to control the On/Off of the modem CPU. The antenna farm referenced contains 4 different communications and tracking modems. Therefore, VBATT is not removed from any device. This is the reason for using PIN 19 set to LOW and using the CPOF command on the Q2686 from the OBA - to place the Q2686 into low power mode… Answer to Question 3: As stated in the initial post, the modem is repowered by the controlling firmware on the ‘DTE’ be placing PIN 19 to a level high. The OBA cannot ask for confirmation that PIN 19 is set LOW. With out going into confidential design detail, suffice it to say that there is no physical way to confirm that PIN 19 is actually set low when the external firmware ( the externa processor, if you will)issues the command to do so. Answer to Question 1: Again, referencing the Q2686 Product Technical Specifications, as stated in the original post, the design follows the specification guidelines. AT+CFUN=1 is not good enough because, as I said, the ‘dte’ is operatinfg in seerial data mode, AND with the modem CPU in low power mode, the OBA is not running and cannot field and serial packets. Using pin 19 is the efficient method of placing the modem in low power modem and at some later time, when the modem is needed for communication, the modem CPU is restarted by setting pin 19 high. Question 4: Tying Pin 19 to a GPIO line is a valid option. I will discuss this with the antenna farm engineers.
a) There’s some non-Wavecom processor that tells others what to do.
b) There’s an FPGA that drives the ON/~OFF pin of the Wavecom modules.
c) There are several Wavecom modules, with common power supply, common RST pin and individual ON/~OFF pins.
Your assumptions in a) and b) are corrected. The assumption in c is incorrect. There is but one Wavecom module and three other dissimilar wireless modules on the antenna farm.
The next paragraph is correct. However, it is not known for sure that PIN 19 is LOW at the time the command is issued. That is the state I am trying to determine before issuing the AT+CPOF command.
Setting a 3 second timer before issuing the AT+CPOF command is not a solution to the problem of making sure pin 19 is low. The external controlling code has effectively done the same thing by delaying the command issued to the Wavecom OBA to shut down the CPU. This does not resolve the problem.
I understand that the AT command reference says that the AT+CPOF command is effectively the same as using the AT+CFUN=1 command. I do not agree for this scenario. Using the AT+CFUN=1 command is not an option - proven by my testing. Secondly I cannot tell the processor (a) that it did not work because once the command is issued, and I have done this with the code setup to have any response to the AT+CPOF command returned to the embedded application, the OS does not return an OK. The target monitoring tool verifies that no AT response was returned by the OS to the OBA after the command is issued. Therefore I have no feedback from the OS.
Additionally, AT+CFUN=1 is basically a command to reset the modem. I do not want to reset the modem. The modem CPU is to be shut down until PIN 19 is set to high. Again I refer to your hardware spec for the usage of pin 19. The process of using pin 19 and the CPOF command to shut down the CPU works as intended when using the Q2686/87 development board. Also, setting pin 19 high restarts the CPU and the OBA. When in the shut down mode, no serial port communincation is possible.
We are currently working on a possible work around by tying a GPIO pin to PIN 19, as you suggested. As soon as I code in the control of the GPIO pin I will be testing this option.
OK. If the ON/~OFF pin is low and OBA issues AT+CPOF, the Q2686 turns off and cannot send any commands. That’s right.
But, your problem is that sometimes ON/~OFF is not low. In this case, the OBA continues to run, and can send messages to the external processor. One such message would be “I tried to power off but I’m still running.”
The other option, issuing AT+CFUN=1 would, of course, not power the Wavecom module off. But, at least, your application would not freeze. OBA would wait for the external processor to start talking to it, prepared to use the GSM network. The only problem is increased power consumption in this rare case.
It’s up to you to decide. I suggest you add one of these options to your application, even if you read the ON/~OFF pin through a GPIO. Better safe than sorry.
Anyway, I wish good luck to you 8)
I will post another note when I figure out the best way to handle this. As I said before, when ever the AT+CPOF command is issued, the OS does not return a response to the command now matter what position the pin 19 is in, so I cannot determine if it worked or not.
The following is my analysis of the operation of the Q2686/87 in regard to PIN 19 usage:
I used the Q26 Product Technical Spec page 49 and 50, the Development Kit Q2686 and Q2687 User GUIDE along with metering what happens on PIN 19 with power to the board and the ON and OFF positions of the switch. I also removed power (VBATT) and performed a continuity check from the switch to PIN 19 in both positions. As to the continuity check, with the switch in the ON position, there is direct connection to VBATT. With the switch in the OFF position the PIN has NO connection to anything. The continuity check was performed with no Q26 module plugged in. When I plugged the module in and applied power, and the switch in the ON position, VBATT (3.8v) was applied to pin 19. With the switch in the OFF position, pin 19 was floating.
Taking all the above information, I have concluded that the modem CPU/OS looks for VBATT on pin 19 at the time power is applied to the modem VBATT pins – 1,2,3,4 . If VBATT is not present at pin 19 the modem CPU will not power on to a run state. If VBATT is present anytime after VBATT is applied to the 4 pins, the modem will begin its startup sequence. VBATT can be removed anytime after more than 1 second has passed. The absence of VBATT on pin 19 after the one second time period has no affect on the modem UNTIL one of three events takes place and PIN 19 is in a float (low, NOT grounded) state: 1) the RESET pin is activated – the modem immediately powers off and will not come back on; 2) issuing the AT+CFUN=1 – works the same as the hard reset; 3) issuing the AT+CPOF command (with no parameters) – in this case the modem does a smooth transition to low power state.
What I have found in testing on the development board is this: if pin 19 has VBATT applied and the CPOF command is issued, the modem returns an OK after a few seconds – I assume looking for a low state on pin 19. The command returns an OK after several seconds and a WIND: 8 (no network connection) is returned ( this is operating in AT mode, not with my application (OBA) running) the modem will respond to AT commands. Evidently only the GSM stack was stopped ( this is consistent with the various documents). But that is all. An AT+CFUN=1 has to be issued or a hard reset to start the stack again. The CPU and hardware layer are NOT shut down. If the embedded application is running, all functions are active, serial interface etc, except no reconnection to the network can be accomplished. Additionally, using the Monitor trace tool, NO OK response is returned to the embedded application even though the response was to be directed to the application. The trace does not show an OK. It does show the WIND: 8.
When PIN 19 has VBATT removed and the CPOF command is issued without any parameters, the GSM stack is shut down and the hardware layer and the modem CPU are shut down, The return to the CPOF command is the same response (OK) and the WIND: 8 event. However, in this case (different from the paragraph above), the application of VBATT to pin 19 acts as a reset to the CPU and it powers back on. This is the methodology that is required in our application of the modem in our hardware environment. I.E the use of PIN 19 as described in this paragraph.
I got a quite similar issue with AT+CPOF, sometimes the modem is not running off, and so the consummation is going high. In our case, the modem is controlled by a PIC which it send AT command.
