ST67W611M1 SPI interface

	Back to main page

1. Introduction

The ST67W611M1 includes a built-in SPI interface for short-range communication. The SPI interface is used in mission mode to manage control and data exchanges between the module and the host. The interface is used to transmit the AT commands.

The SPI bus is configured in full-duplex target mode with five signals mapped to five dedicated module pins:

• SPI_CS (24) pin: Input. Chip select signal from the SPI controller to the module.
• SPI_CLK (28) pin: Input. SPI clock generated by the SPI controller.
• SPI_MOSI (27) pin: Input. SPI data from the SPI controller to the module.
• SPI_MISO (29) pin: Output. SPI data from the module to the SPI controller.
• SPI_RDY (21) pin: Output. SPI ready signal from the module to the SPI controller.

The SPI_CS (24) pin can also convey a wake-up signal from the host. Refer to the wake-up section for additional details.

2. SPI bus specification

2.1. SPI transfer sequence

SPI_CS and SPY_RDY are two control signals used to ensure correct SPI data transfer:

• When the SPI controller has data to transfer, it raises SPI_CS and waits for the readiness of the target ST67W611M1 module, which is indicated by SPI_RDY signal or interrupt. Once the module raises SPI_RDY, the controller enables SPI_CLK and sends and/or receives the data on SPI_MOSI and SPI_MISO. The host stops SPI_CLK and lowers SPI_CS when the transfer is completed.
  

• When the target ST67W611M1 module has data to transfer, it raises SPI_RDY signal or interrupt to inform the SPI controller. The controller then raises SPI_CS and enables SPI_CLK in order to receive the data on SPI_MISO and send data on SPI_MOSI, if available. The controller stops SPI_CLK and lowers SPI_CS when the transfer is complete.
  

• Since the SPI bus is configured in full-duplex mode, both of the above situations can be used to send and receive data simultaneously. For example, if the transfer is initiated by the ST67W611M1 module (by raising SPI_RDY), the host starts the SPI transaction with a length of TX_bytes. If RX_bytes is greater than TX_bytes, the host continues to generate additional [RX_bytes - TX_bytes] clock cycles to receive the remaining data bytes from the ST67W611M1.

Warning

Depending on the SPI controller implementation, SPI_CS may be deasserted by the controller before the ST67W611M1 module deasserts SPI_RDY. In such cases, the controller must wait until SPI_RDY is deasserted before asserting SPI_CS again and initiating a new transfer. Failing to comply may cause the module to enter an error state.

2.2. SPI frame format

The data payload, with a length of DL in bytes, to be transmitted is encapsulated in a frame of variable length. The frame consists of an 8-byte header followed by the data payload. DL can range from 0 to 65,535¹ and must be a multiple of 4. If DL is not a multiple of 4, the frame must be padded with 1, 2, or 3 additional bytes with the value 0x88². The header consists of the following fields:

• Sync word: A 2-byte field with a fixed value of 0x55AA. It is transmitted with the lower byte first and indicates a valid SPI frame.
• Data length: A 2-byte field with a value equal to DL. It is transmitted with the lower byte first and indicates the data payload length.
• Frame: A 1-byte field that has the following content:
  • bits [0:1]: version. Set to 0.
  • bit [2]: rx_stall. When 1, it indicates that the ST67W611M1 RX is stalled³.
  • bits [3:7]: flags.
• Type: A 1-byte field that indicates the traffic type as follows:
  • 0x00: AT commands.
  • 0x01: Station mode data.
  • 0x02: Access Point mode data.
• Reserved: A 2-byte field reserved for future extensions. It is set to 0x0000.

¹ While two bytes are available for data length (DL) specification, theoretically allowing a value up to 65,535, transmitting very large frames impacts the application's memory allocation. The X-CUBE software sets a default data length of 1300 bytes and allows a maximum of 6000 bytes. Users must select a value balancing memory allocation and achievable throughput. Refer to the X-CUBE-ST67W61 overview page for additional information.
² When adding padding to the payload, the ST67W611M1 uses bytes with the value 0x00.
³ This situation occurs when the SPI transaction is initiated by the ST67W611M1 module, and the host intends to to use the transaction to transmit data. If the module cannot receive any data during the transaction, it sends its header with the rx_stall bit set. The host should finish the current transaction and retransmit its data in a separate transaction.

2.3. SPI timings specification

The image and table below show the timing relationship between SPI_CLK, SPI_MISO and SPI_MOSI.

Symbol	Description	Min	Max	Unit
Tcyc	SPI_CLK clock period	254	-	ns
Ts	MOSI setup time	6	-	ns
Th	MOSI hold time	6	-	ns
Tvld	MISO output delay	-	8	ns

⁴ This means a maximum frequency of 40 MHz.

3. SPI hardware implementation

The module SPI pins must be connected to the host's corresponding SPI pins. Three aspects must be considered when routing the SPI signals:

• Signal integrity: Route these tracks with impedance control targeting 50 Ohms. Exercise caution when changing layers. Use coplanar routing (i.e. to separate these signals with ground) to avoid coupling. Ensure SPI signals are routed away from sensitive or noisy signals, such as RF signals or power supply sources.
• SPI maximum frequency: The SPI clock maximum frequency is specified at 40 MHz. To achieve this frequency, integrators must minimize the length of SPI_CLK, SPI_MOSI and SPI_MOSI tracks on their boards to reduce propagation delay and skew between SPI_MISO and SPI_CLK at the host side. Verify the module and host SPI capabilities.
• Electromagnetic compatibility (EMC): Ensure SPI signal routing and board layout comply with EMC certification requirements. On a four-layer board, route SPI signals on inner layers to minimize SPI_CLK radiation. For other board stack-ups, perform EMC simulations or measurements.

It is recommended to refer to ST's ST67W611M1 reference designs for implementation guidelines.

4. SPI software implementation

4.1. Interface configuration

In the X-CUBE-ST67W61 software package, the SPI controller's main configuration is as follows:

• Data size = 8 bits
• POL = 0
• PHA = 0
• First bit = MSB

4.2. Start-up sequence

The following sequence must be followed before interacting with the ST67W611M1 module:

1. The host sets the CHIP_EN pin high.
2. The host waits for the module to assert the SPI_RDY pin.
3. The module asserts the SPI_RDY.
4. The module transmits "ready" and the host receives it over SPI.
5. The host transmits "AT" over SPI. Refer to the warning here.
6. The module replies with "OK".

Steps 5 and 6 are not strictly necessary, but they are good practice to verify basic functionality.

4.3. AT commands and SPI

Commands are ASCII AT-style strings that end with \r\n. Each command generates an immediate response that indicates the success or failure of the command. Responses are also terminated with \r\n. For additional details on the various AT commands and response types, refer to the AT commands page .

SET and EXECUTE commands typically generate a single response, such as "OK" or "ERROR". Some commands additionally produce ">", which indicates that the ST67W611M1 is ready to receive an additional data frame.

For QUERY commands, the response consists of two parts: a response with data corresponding to the query, followed by "OK". The "busy p" response indicates that the ST67W611M1 is busy, but it continues with execution and response in the next frame.

Some AT commands require the host to send data in a separate SPI frame. These commands are typically used for writing into the FLASH or EFUSE region, sending data on a UDP/TCP port, publishing data on MQTT, or updating BLE characteristics data. After receiving one of these commands, the ST67W611M1 responds with "OK". The host is then expected to transmit the data with the length specified in the command frame. The ST67W611M1 indicates successful or failed reception of the data by responding with either "SEND OK" or "SEND FAIL".

Certain commands, such as Wifi scan, produce an initial "OK" response and the ST67W611M1 later sends the result of the operation in a separate report. User actions, such as receiving data from a connected device, also elicit a report. These reports can generally arrive at any time, even between a command and its response.

5. SPI transfer examples

5.1. The ST67W611M1 requests a data transfer

In this example, the ST67W611M1 sends the \r\nready\r\n message right after it completes its initialization. The host doesn't have any data to transfer.
Global view (click to enlarge):

Zoom on the header (click to enlarge):

Zoom on the payload (click to enlarge):

5.2. The hosts requests a data transfer

In this example, CLI application is used, and a wifi_scan command is entered on the UART terminal. This is equivalent to sending AT command AT+CWLAPOPT=1695,-100,255,50\r\n to the ST67W611M1. The module does not have any data to transfer, but it sends a repeated (DDCCBBAA) dummy sequence until the host is finished.
Global view (click to enlarge):

Zoom on the header and payload (click to enlarge):