GS2101M IP2WiFi Adapter Command Reference Guide
1VV0301499
Rev. 2.0
32
2019-08-05
3.1 Startup Handling
3.1.1 Single Interface Startup Handling
For proper synchronization between Host micro controller (MCU) and GS node (IP2WiFi
Application), the following steps must be followed:
1. Once the GS node is up, Host MCU needs to first read the complete IP2WiFi start-up
banner
r\nIP2WiFi<SP>APP\r\n
before issuing any command.
2. If the Host MCU misses the startup banner, then it needs to send dummy AT command
until it receives
\r\nOK\r\n
response from GS node (IP2WiFi Application).
3. In case of SPI interface, following SPI mechanisms are supported in IP2WiFi
Application:
–
SPI Byte Stuffing
–
SPI Command Response (High speed)
Host MCU needs to check the status of host wake-up signal (GPIO37 for GS2000 based
modules) after boot up. Once the Host MCU wake-up signal is HIGH, then it needs to
read the “
r\nIP2WiFi<SP>APP\r\n
” banner which is queued up for transmission at
the GS node’s SPI interface.
In case of
SPI Byte Stuffing
,
Host MCU repeatedly transmit s idle characters (F5) over the SPI line and reads the
characters transmitted by GS node (“
r\nIP2WiFi<SP>APP\r\n
” banner) until it sees
that the host wake-up signal line is LOW which indicates that all the characters
transmitted from GS node have been read. At this point, the Host MCU can send any
AT commands to the GS node. Host MCU must not issue a reset using the ext_reset_n
signal until initialization process is complete.
In case of
SPI Command Response
,
Host MCU issues READ_REQUEST and waits for READ_RESPONSE. Once the
Host MCU receives the READ_RESPONSE from GS node, it reads the
DAT_HEADER and the DATA from GS node. Data part will have the boot-up banner
“
r\n
IP
2WiFi<SP>APP\r\n
”.
SPI Byte Stuffing (Legacy SPI, SPI-NO-DMA), page 38
and
SPI Command Response (SPI-DMA), page 39
4. In case of SDIO interface, once the Host MCU SDIO interface is initialized and
synchronized with the GS node, it reads the boot-up banner
“
r\nIP2WiFi<SP>APP\r\n
” from GS node.
