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.
Feel free to ask question of me about this.