(→‎Eliminating echo on the non-neo end (far end) of phone calls: +link)

(23 intermediate revisions by 8 users not shown)

Line 1:

Line 1:

−

This page is about the [[Neo1973]] GTA01 (and GTA02) GSM Modem, based on the Ti Calypso chipset.

+

This page is about the [[Neo1973]] and [[Neo FreeRunner]] GSM Modem, based on the Ti Calypso chipset.

== [[Hardware:AT Commands|AT command]] interface ==

== [[Hardware:AT Commands|AT command]] interface ==

Line 6:

Line 6:

To send commands to the GSM modem, you may use

To send commands to the GSM modem, you may use

cu -l /dev/ttySAC0

cu -l /dev/ttySAC0

−

or use gsmd and libgsmd-tool for a less direct method.

+

or use [[gsmd]] and libgsmd-tool for a less direct method.

If you connect directly (via cu) you must `chown uucp.uucp /dev/ttySAC0` first since cu is picky about permissions.

If you connect directly (via cu) you must `chown uucp.uucp /dev/ttySAC0` first since cu is picky about permissions.

Line 23:

Line 23:

=== TI proprietary AT commands ===

=== TI proprietary AT commands ===

−

there are a few of them, but none of them are really required for regular operation of the device. Due to NDA issues, OpenMoko cannot provide a reference documentation to those commands. Using the standards-compliant '''AT+CLAC''', you will notice that the non-standard commands also show up in the command listing.

+

there are a few of them, but none of them are really required for regular operation of the device. Due to NDA issues, Openmoko cannot provide a reference documentation to those commands. Using the standards-compliant '''AT+CLAC''', you will notice that the non-standard commands also show up in the command listing.

You will also notice that those non-standard commands are prefixed with '''AT%''' rather than '''AT+''' for the standards-compliant commands.

You will also notice that those non-standard commands are prefixed with '''AT%''' rather than '''AT+''' for the standards-compliant commands.

The Ti calypso GSM Modem firmware has been extended by OpenMoko specific AT

+

The Ti calypso GSM Modem firmware has been extended by Openmoko specific AT

commands. This page documents those commands.

commands. This page documents those commands.

Line 552:

Line 583:

This also means that gsmd will eventually have to re-program the GSM modem to make sure only relevant unsolicited response codes are sent during suspend. You usually don't want a signal level change to cause a CPU wake up, only things like incoming message / call.

This also means that gsmd will eventually have to re-program the GSM modem to make sure only relevant unsolicited response codes are sent during suspend. You usually don't want a signal level change to cause a CPU wake up, only things like incoming message / call.

−

Upgrading the modem's firmware is technically possible but no proper software is currently legally available to users outside OpenMoko staff.

+

Upgrading the modem's firmware is technically possible but no proper software is currently legally available to users outside Openmoko staff.

+

[edit jOERG 2009-04-02] There's FLUID software and GSM-FW-images as well as a uSD-image for automatic update (this GTA02 for now) now. See [[GSM/Flashing]]

== Power On, Power Off, and Reset of the GTA01 GSM Modem ==

== Power On, Power Off, and Reset of the GTA01 GSM Modem ==

Line 627:

Line 659:

You probably actually want the GSM modem to turn off automatically when you power down the Neo. Right now, there is no functionality available from the modem while the Neo is powered off, so it's just a waste of power. See [[GSMPowerDownInitScript]].

You probably actually want the GSM modem to turn off automatically when you power down the Neo. Right now, there is no functionality available from the modem while the Neo is powered off, so it's just a waste of power. See [[GSMPowerDownInitScript]].

−

=== Eliminating echo on the non-neo end of phone calls ===

+

=== Eliminating echo on the non-neo end (far end) of phone calls ===

−

Modify your /etc/gsmhandset.state as specified at the end of [[User:TonyGarnockJones]]

+

Issue appropriate AT%Nxxxx command to enable AEC ([http://wiki.openmoko.org/wiki/Hardware:AT_Commands#Echo_Suppression_and_Noise_Reduction Echo Cancellation]) in calypso. Has to be done per-call as it's not "sticky" (=after modem-powerup/init and after every call). Recent GSM-handling-daemons (as of Apr 2009) tend to finally implement this function.

+

+

This echo issue isn't considered to be fixable for good by modifying mixer-settings, as you always get a tradeoff resulting in either low earpiece volume or poor mic-sensitivity.

there are a few of them, but none of them are really required for regular operation of the device. Due to NDA issues, Openmoko cannot provide a reference documentation to those commands. Using the standards-compliant AT+CLAC, you will notice that the non-standard commands also show up in the command listing.

You will also notice that those non-standard commands are prefixed with AT% rather than AT+ for the standards-compliant commands.

Thus, we welcome our user and developer community to play with those commands and document them here. Since we never have released any NDA documentation to our community, there is no legal issue.

Note that the syntax and the interpretation of the output of the commands listed here are only educated guesses and should not be relied on. Part of the proprietary command set has identical or similar usage as on other modems in the market, some of which have fully opened specifications and information about these commands can be taken from their datasheets (some known similar modems with open specs: BenQ M22A and M23A, Enfora Enabler-G II / III and SPT 1834).

The second column lists firmware component names (e.g. aci = AT Command Interface). The third column is the user name of the engineer who last modified given component. The rightmost column is probably the last time someone worked on it (Please note that the name 'sean' here is not Sean Moss-Pultz :) while a086 is an anonymous TI engineer's nick, meaning that the component has not been modified at FIC).

This command is not listed in AT+CLAC output but it is triggered by any input that starts with AT%A except AT%ALS (Alternative Line Service) and AT%ATR, which are other proprietary AT commands. So for example AT%ABCD,HELLO will also run this commands. On my Neo modem it prints a line containing nine values of the form ADC <number> = <value>:

It would seem there's an ADC (analog-to-digital converter) module in the modem with nine input lines connected to it and the values on these lines are reported by this command in hexadecimal format. The values change over time. Inputs 1 and 7 always show zero on my modem, input 1 value changes slightly (+/- 20), while values on inputs 3, 4, 5, 6 and 8 change seemingly randomly in the range 0x000 - 0xfff (it would seem the chip is 12-bit).

The AT%NRG (Network registration and service selection) is an expansion of the AT+COPS command. It allows specifying the service state of the registration, in addition to AT+COPS functionality. It doesn't however allow listing all present operators (use AT+COPS for this).

Execution of Engineering Mode commands. Allows viewing the information accessible to the modem but not available through standard GSM AT commands set such as detailed information on the current Serving Cell (the one we're registered with), its neighbouring cells, the GPRS/EDGE availability and SIM card data.

Citing Enfora Inc. Application Note EDG0108TN01:
The purpose of Engineering Mode (EM) is to provide means to observe the behavior of the mobile station and the settings of the network as counterpart and therefore defines a lot of possibilities to analyze the network. The EM can be used for observation of a defined data set during functional test and field test.

Warning: The display of certain parameters is dependent on the wireless network sending the correct information in the System Information Packets. There is no guaranty that the information is always forwarded from the network. At times data may not be present to display in the Engineering Mode responses.

Syntax:

AT%EM=<mode>,<command>

Allowed <mode> values:

2 - AT command mode

3 - PCO mode

I only describe the AT mode commands here. Commands are in range 1 to 13:

Notice the 1800 and 1900 bands have the same channel ids and nearly the same algorithm with a different starting point.

According to this mail the distance from the Base Station can be calculated using the tav field in 550-metre steps. This information together with the list of neighbouring cells could be used for geolocation and potentially yield better results than using Signal-quality values for that.

The first line of response is of the format %EM: <number of cells listed>, where the maximum seems to be 6, one cell for each channel. The next sixteen lines list the values of each of the parameters for each of the cells.

The MCC and MNC values are the same values that are used to form the Mobile Operator names used by the standard AT+COPS and AT+COPN commands in numeric format. The TMSI is the same number that AT%EM=2,8 gives, just in a different format.

The IMEISV line contains 20 numbers separated by commas, the numbers on positions 5 to 18 are the digits of the IMEI number as returned by AT+CGSN. The second line contains another 20 numbers and the numbers on positions 5 to 19 form the digits of your SIM card's IMSI number, as returned by the AT+CIMI command. The last line contains the Temporary Mobile Subscriber Identity number in plain format (ten digits).

Prints version information for different components of the modem's firmware. The format and the scope of the information presented is identical to that in AT%VER output with the exception that only a subset of all of the components are listed:

For power management reasons, it is absolutely neccessary that only the minimal
required parts of the device are powered at any given time. If you carry your
Neo in your pocket, then all it should do is stay online with the GSM network,
and notify you in case there's an incoming call/sms (like other phones).

During that time, the Neo1973 Application Processor (s3c24xx) is suspended,
i.e. not powered at all. The SDRAM is in self-refresh mode.

In this suspend mode (which Samsung calls by the funny name of POWER_OFF), the
processor is not able to receive any data from the GSM Modem. Nor is it able
to detect incoming characters and wake up the CPU. The only wake up sources
are a certain set of external interrupts (EINT).

Thus, the GSM Modem GPIO line IO1 was connected with the Samsung EINT1, and
the GSM Modem firmware contains some special logic to generate an interrupt
(and thus wake-up event) to the CPU.

a firmware post may-16-2007 needs to be present in the gsm modem. This is true for all phones bought during phase 1 in the online shop. However, I currently don't really know what firmware version was present in the GTA01Bv4 that we sent to phase 0.

the suspend code probably still needs to correctly configure the RTS/CTS lines (i.e. put them in GPIO mode, and set them to their desired "don't send any more characters" level)

So in this case, any data from the GSM modem will wake up the cpu for processing of that data. The GSM modem has some internal buffer (I don't know how big right now) that should be sufficient for buffering the data until the CPU is alive.

This also means that gsmd will eventually have to re-program the GSM modem to make sure only relevant unsolicited response codes are sent during suspend. You usually don't want a signal level change to cause a CPU wake up, only things like incoming message / call.

Upgrading the modem's firmware is technically possible but no proper software is currently legally available to users outside Openmoko staff.
[edit jOERG 2009-04-02] There's FLUID software and GSM-FW-images as well as a uSD-image for automatic update (this GTA02 for now) now. See GSM/Flashing

The GTA01 GSM modem communicates via a standard serial port to the host system. The port operates at 115200 baud, 8 bits, no parity, and requires hardware flow control (RTSCTS) to operate. Due to the fact that the host CPU has only a pair of serial ports but there are three devices that wish to use them, the GSM modem port is actually shared with the serial console (the third device is the GPS chip, which has exclusive use of the second serial port).

A GPIO (General Purpose IO) pin controls the switching of the serial port between the console and the GSM modem. Another GPIO is used to turn on the power to the GSM modem. On older versions of the GTA01 a third GPIO could be used to reset the GSM modem; this signal proved to cause difficulties with the modem, and on all the GTA01 units sold this GPIO line is not connected. The driver combines the the switching of the serial port to the GSM modem and the power-on signal to the modem into a single operation; the two cannot be controlled independently from user-space (at the time of this writing).

It is important to note that the GPIO controlling the power-on of the GSM modem can only signal to the modem to turn itself on -- turning this GPIO off does not power off the GSM modem. Instead, the AT@POFF sequence must be sent to the modem in order to perform a power off.

Further complicating power control of the GTA01 GSM modem is the fact that the modem draws power from the battery/charger side of the power management circuitry -- this means that turning off the power to the host CPU on the GTA01 does not turn off the power to the modem. In real-world operation, this means that unless the shutdown procedure for the host cpu's operating system issues the AT@POFF command to power off the GSM modem, the modem will remain turned on, drawing power from the battery even thought the host CPU is completely powered off.

The sharing of the serial port between the console and the GSM modem results in the need for a very specific power-on and power-off sequence. Two major problems exist that must be avoided: infinite echos, and RTSCTS lockup.

By default, the serial port is initialized in "echo" mode -- meaning that any characters sent to the serial port from the console will be echoed back to the console. Upon power-up or reset, the GSM modem also echos back characters it receives. So unless action is taken to disable the serial port's echo before the GSM modem is powered on, an infinite echo will result. The modem will print the standard "Interpretor Ready" message, which will be echoed back to it by the serial port driver, the modem will echo that back to the serial port again (adding some error text to the message), the serial port will echo that again, and this continues until buffers in either or both the serial port and the modem fill up, and one of them ceases to transmit.

Once in this situation, it is difficult for software (such as gsmd) to gain synchronization of commands and responses.

The best solution is to avoid the problem to begin with. Simply ensure that the serial port is set to "no-echo" mode before the GSM modem is enabled and powered up. This sequence illustrates how this is normally done:

Hardware flow control uses additional signals in addition to the serial data in and out signals on the serial port to control the flow of the data. Specifically, when hardware flow control is enabled, a given endpoint is expected to assert its RTS (Request To Send) line when it has data to transmit, and not transit that data until it sees a CTS (Clear TO Send) signal from the other end. In this fashion, buffer overruns and data loss are avoided.

The GSM modem requires that hardware flow control be enabled in order to communicate with the host. However, the console lacks the RTS and CTS signals and thus is unable to communicate if hardware flow control is enabled. But what really makes this problem serious is that if hardware flow control is enabled while the serial port is switched to the console, and the (small) transmit buffer for the port fills (such as a kernel log message), the Linux kernel will lock up, and become completely non-responsive. There is no recovery mechanism for this other than to disconnect the device from its USB port or charger, and remove the battery.

One solution to this is to disable the use of the serial port as a console for the kernel. However, this is greatly inconvenient - the knowledgeable user with a debug board will usually wish to have a console available, and the novice user will probably wish to avoid changing the u-boot variables in order to disable the console. So, a better approach is to avoid this situation by taking great care when powering-up, resetting, or powering-down the modem. The following sequence illustrates how to switch the serial port back to the console mode safely:

The GSM modem can be effectively reset by changing the state of the Power-On GPIO from off to on -- in other words, just disable the GSM modem and re-enable it. The safe way to accomplish this is to combine the two sequences above:

It should be noted that this reset sequence will also power up the modem if it is not enabled and powered up to begin with. For this reason, the reset sequence above should be used for both power-up and reset purposes.

Powering off the GSM modem on the GTA01 can only be done by issuing the AT@POFF command to the device. In order to issue this command, it is usually necessary to return it to a known state. So the normal mechanism is to issue the reset operation (above), wait for a short period of time (1 second seems to be sufficient), and send the AT@POFF command. This should be followed by an additional short delay (to allow the text to be transmitted), and then the serial port can be switched back to the console. The following script accomplishes this:

You probably actually want the GSM modem to turn off automatically when you power down the Neo. Right now, there is no functionality available from the modem while the Neo is powered off, so it's just a waste of power. See GSMPowerDownInitScript.

Issue appropriate AT%Nxxxx command to enable AEC (Echo Cancellation) in calypso. Has to be done per-call as it's not "sticky" (=after modem-powerup/init and after every call). Recent GSM-handling-daemons (as of Apr 2009) tend to finally implement this function.

This echo issue isn't considered to be fixable for good by modifying mixer-settings, as you always get a tradeoff resulting in either low earpiece volume or poor mic-sensitivity.

Standard AT commands

TI proprietary AT commands

there are a few of them, but none of them are really required for regular operation of the device. Due to NDA issues, OpenMoko cannot provide a reference documentation to those commands. Using the standards-compliant AT+CLAC, you will notice that the non-standard commands also show up in the command listing.

You will also notice that those non-standard commands are prefixed with AT% rather than AT+ for the standards-compliant commands.

Thus, we welcome our user and developer community to play with those commands and document them here. Since we never have released any NDA documentation to our community, there is no legal issue.

Note that the syntax and the interpretation of the output of the commands listed here are only educated guesses and should not be relied on. Part of the proprietary command set has identical or similar usage as on other modems in the market, some of which have fully opened specifications and information about these commands can be taken from their datasheets (some known similar modems with open specs: BenQ M22A and M23A, Enfora Enabler-G II / III and SPT 1834).

AT%VER

Prints the firmware component versions.

The modem's response looks like this on an un-updated phase-0 GTA01Bv4 phone:

The second column lists firmware component names (e.g. aci = AT Command Interface). The third column is the user name of the engineer who last modified given component. The rightmost column is probably the last time someone worked on it (Please note that the name 'sean' here is not Sean Moss-Pultz :) while a086 is an anonymous TI engineer's nick, meaning that the component has not been modified at FIC).

AT%A

Print values from an ADC.

This command is not listed in AT+CLAC output but it is triggered by any input that starts with AT%A except AT%ALS (Alternative Line Service) and AT%ATR, which are other proprietary AT commands. So for example AT%ABCD,HELLO will also run this commands. On my Neo modem it prints a line containing nine values of the form ADC <number> = <value>:

It would seem there's an ADC (analog-to-digital converter) module in the modem with nine input lines connected to it and the values on these lines are reported by this command in hexadecimal format. The values change over time. Inputs 1 and 7 always show zero on my modem, input 1 value changes slightly (+/- 20), while values on inputs 3, 4, 5, 6 and 8 change seemingly randomly in the range 0x000 - 0xfff (it would seem the chip is 12-bit).

AT%NRG

The AT%NRG (Network registration and service selection) is an expansion of the AT+COPS command. It allows specifying the service state of the registration, in addition to AT+COPS functionality. It doesn't however allow listing all present operators (use AT+COPS for this).

AT%EM

Execution of Engineering Mode commands. Allows viewing the information accessible to the modem but not available through standard GSM AT commands set such as detailed information on the current Serving Cell (the one we're registered with), its neighbouring cells, the GPRS/EDGE availability and SIM card data.

Citing Enfora Inc. Application Note EDG0108TN01:
The purpose of Engineering Mode (EM) is to provide means to observe the behavior of the mobile station and the settings of the network as counterpart and therefore defines a lot of possibilities to analyze the network. The EM can be used for observation of a defined data set during functional test and field test.

Warning: The display of certain parameters is dependent on the wireless network sending the correct information in the System Information Packets. There is no guaranty that the information is always forwarded from the network. At times data may not be present to display in the Engineering Mode responses.

Syntax:

AT%EM=<mode>,<command>

Allowed <mode> values:

2 - AT command mode

3 - PCO mode

I only describe the AT mode commands here. Commands are in range 1 to 13:

Notice the 1800 and 1900 bands have the same channel ids and nearly the same algorithm with a different starting point.

According to this mail the distance from the Base Station can be calculated using the tav field in 550-metre steps. This information together with the list of neighbouring cells could be used for geolocation and potentially yield better results than using Signal-quality values for that.

Neighbour Cell Information (2,3)

The first line of response is of the format %EM: <number of cells listed>, where the maximum seems to be 6, one cell for each channel. The next sixteen lines list the values of each of the parameters for each of the cells.

The MCC and MNC values are the same values that are used to form the Mobile Operator names used by the standard AT+COPS and AT+COPN commands in numeric format. The TMSI is the same number that AT%EM=2,8 gives, just in a different format.

Identity Parameters (2,8)

Response format:

%EM: <imeisv>
<imsi>
<tmsi>
OK

The IMEISV line contains 20 numbers separated by commas, the numbers on positions 5 to 18 are the digits of the IMEI number as returned by AT+CGSN. The second line contains another 20 numbers and the numbers on positions 5 to 19 form the digits of your SIM card's IMSI number, as returned by the AT+CIMI command. The last line contains the Temporary Mobile Subscriber Identity number in plain format (ten digits).

Firmware components versions (2,9)

Prints version information for different components of the modem's firmware. The format and the scope of the information presented is identical to that in AT%VER output with the exception that only a subset of all of the components are listed:

The audio table will be stored in the flash file system within GSM modem, you can load it through this command.

For now, we only provide one configuration, that is "0".

If AT@AUL="0" responds with ERROR, it means there's no audio table existing and the GSM firmware will use default values.

Wakeup of CPU from GSM Modem

Problem description

For power management reasons, it is absolutely neccessary that only the minimal
required parts of the device are powered at any given time. If you carry your
Neo in your pocket, then all it should do is stay online with the GSM network,
and notify you in case there's an incoming call/sms (like other phones).

During that time, the Neo1973 Application Processor (s3c24xx) is suspended,
i.e. not powered at all. The SDRAM is in self-refresh mode.

In this suspend mode (which Samsung calls by the funny name of POWER_OFF), the
processor is not able to receive any data from the GSM Modem. Nor is it able
to detect incoming characters and wake up the CPU. The only wake up sources
are a certain set of external interrupts (EINT).

Thus, the GSM Modem GPIO line IO1 was connected with the Samsung EINT1, and
the GSM Modem firmware contains some special logic to generate an interrupt
(and thus wake-up event) to the CPU.

once all data is transmitted, return to idle state. When next data item is to be transmitted, start again from '1'

Software implementation

NOTE: This is the plan, it has not been fully implemented yet

a firmware post may-16-2007 needs to be present in the gsm modem. This is true for all phones bought during phase 1 in the online shop. However, I currently don't really know what firmware version was present in the GTA01Bv4 that we sent to phase 0.

the suspend code probably still needs to correctly configure the RTS/CTS lines (i.e. put them in GPIO mode, and set them to their desired "don't send any more characters" level)

So in this case, any data from the GSM modem will wake up the cpu for processing of that data. The GSM modem has some internal buffer (I don't know how big right now) that should be sufficient for buffering the data until the CPU is alive.

This also means that gsmd will eventually have to re-program the GSM modem to make sure only relevant unsolicited response codes are sent during suspend. You usually don't want a signal level change to cause a CPU wake up, only things like incoming message / call.

Upgrading the modem's firmware is technically possible but no proper software is currently legally available to users outside OpenMoko staff.

Power On, Power Off, and Reset of the GTA01 GSM Modem

GSM Modem Connections

The GTA01 GSM modem communicates via a standard serial port to the host system. The port operates at 115200 baud, 8 bits, no parity, and requires hardware flow control (RTSCTS) to operate. Due to the fact that the host CPU has only a pair of serial ports but there are three devices that wish to use them, the GSM modem port is actually shared with the serial console (the third device is the GPS chip, which has exclusive use of the second serial port).

A GPIO (General Purpose IO) pin controls the switching of the serial port between the console and the GSM modem. Another GPIO is used to turn on the power to the GSM modem. On older versions of the GTA01 a third GPIO could be used to reset the GSM modem; this signal proved to cause difficulties with the modem, and on all the GTA01 units sold this GPIO line is not connected. The driver combines the the switching of the serial port to the GSM modem and the power-on signal to the modem into a single operation; the two cannot be controlled independently from user-space (at the time of this writing).

It is important to note that the GPIO controlling the power-on of the GSM modem can only signal to the modem to turn itself on -- turning this GPIO off does not power off the GSM modem. Instead, the AT@POFF sequence must be sent to the modem in order to perform a power off.

Further complicating power control of the GTA01 GSM modem is the fact that the modem draws power from the battery/charger side of the power management circuitry -- this means that turning off the power to the host CPU on the GTA01 does not turn off the power to the modem. In real-world operation, this means that unless the shutdown procedure for the host cpu's operating system issues the AT@POFF command to power off the GSM modem, the modem will remain turned on, drawing power from the battery even thought the host CPU is completely powered off.

The Power-On Sequence

The sharing of the serial port between the console and the GSM modem results in the need for a very specific power-on and power-off sequence. Two major problems exist that must be avoided: infinite echos, and RTSCTS lockup.

Avoiding Infinite Echos

By default, the serial port is initialized in "echo" mode -- meaning that any characters sent to the serial port from the console will be echoed back to the console. Upon power-up or reset, the GSM modem also echos back characters it receives. So unless action is taken to disable the serial port's echo before the GSM modem is powered on, an infinite echo will result. The modem will print the standard "Interpretor Ready" message, which will be echoed back to it by the serial port driver, the modem will echo that back to the serial port again (adding some error text to the message), the serial port will echo that again, and this continues until buffers in either or both the serial port and the modem fill up, and one of them ceases to transmit.

Once in this situation, it is difficult for software (such as gsmd) to gain synchronization of commands and responses.

The best solution is to avoid the problem to begin with. Simply ensure that the serial port is set to "no-echo" mode before the GSM modem is enabled and powered up. This sequence illustrates how this is normally done:

Avoiding RTSCTS Lockup

Hardware flow control uses additional signals in addition to the serial data in and out signals on the serial port to control the flow of the data. Specifically, when hardware flow control is enabled, a given endpoint is expected to assert its RTS (Request To Send) line when it has data to transmit, and not transit that data until it sees a CTS (Clear TO Send) signal from the other end. In this fashion, buffer overruns and data loss are avoided.

The GSM modem requires that hardware flow control be enabled in order to communicate with the host. However, the console lacks the RTS and CTS signals and thus is unable to communicate if hardware flow control is enabled. But what really makes this problem serious is that if hardware flow control is enabled while the serial port is switched to the console, and the (small) transmit buffer for the port fills (such as a kernel log message), the Linux kernel will lock up, and become completely non-responsive. There is no recovery mechanism for this other than to disconnect the device from its USB port or charger, and remove the battery.

One solution to this is to disable the use of the serial port as a console for the kernel. However, this is greatly inconvenient - the knowledgeable user with a debug board will usually wish to have a console available, and the novice user will probably wish to avoid changing the u-boot variables in order to disable the console. So, a better approach is to avoid this situation by taking great care when powering-up, resetting, or powering-down the modem. The following sequence illustrates how to switch the serial port back to the console mode safely:

Resetting the GSM Modem

The GSM modem can be effectively reset by changing the state of the Power-On GPIO from off to on -- in other words, just disable the GSM modem and re-enable it. The safe way to accomplish this is to combine the two sequences above:

It should be noted that this reset sequence will also power up the modem if it is not enabled and powered up to begin with. For this reason, the reset sequence above should be used for both power-up and reset purposes.

Powering Off the GSM Modem

Powering off the GSM modem on the GTA01 can only be done by issuing the AT@POFF command to the device. In order to issue this command, it is usually necessary to return it to a known state. So the normal mechanism is to issue the reset operation (above), wait for a short period of time (1 second seems to be sufficient), and send the AT@POFF command. This should be followed by an additional short delay (to allow the text to be transmitted), and then the serial port can be switched back to the console. The following script accomplishes this:

You probably actually want the GSM modem to turn off automatically when you power down the Neo. Right now, there is no functionality available from the modem while the Neo is powered off, so it's just a waste of power. See GSMPowerDownInitScript.