SPI Communication with NINA-W132 Wi-Fi Module

[nithin3200]

Hi,

I'm interfacing the NINA-W132 Wi-Fi module (SPI Slave) with an LPC54618 microcontroller (SPI Master) over SPI using MISO, MOSI, CS, and CLK (without DRDY or RESET), configured to Mode 3 (CPOL=1, CPHA=1) (also tested Mode 1) with an 8 MHz clock speed (datasheet max: 10 MHz) and a minimum transaction length of 8 bytes, while debugging responses via USART.

However, when sending the "AT" command (formatted as an 8-byte SPI transaction) and expecting an "OK" response (0x4F4B in Hex), I consistently receive unexpected values or garbage data.

I would like to know if anyone has successfully communicated with NINA-W132 over SPI, if there are any special initialization steps required before sending AT commands, whether timing issues could be affecting communication, or if extra dummy bytes are needed in SPI transactions.

[Harry_Zhang]

Hi @nithin3200 

Some SPI devices, including the NINA-W132, require a special initialization sequence before AT commands will work correctly. Make sure you're following the proper initialization steps outlined in the datasheet or reference manuals.

BR

Harry

[nithin3200]

Hi @Harry_Zhang ,

Thank you for your reply. After referring to the reference manual, my understanding is that the SPI control protocol follows a packet structure consisting of a 4-byte header followed by a payload. The first two bytes serve as a preamble, while the last two contain packet information. A packet begins with Chip Select (CS) assertion, and the format varies depending on the direction of data transfer between the host and module.

Example:

Header: 0xBA 0x15 0x00 0x02

Payload: 0x41 0x54 

Is there anything else I should take care of?

[Harry_Zhang]

Hi @nithin3200 

If you receive unexpected values, verify that byte alignment is correct.

Capture and analyze SPI transactions with a logic analyzer to confirm that the header and payload are sent and received correctly.

BR

Harry

[nithin3200]

Hi @Harry_Zhang,

Thank you for your reply. The header and payload are being sent and received, but while the header is received correctly, the payload appears to be corrupted. The CS and SCLK signals look fine.

According to the user manual:
During startup, the module toggles DRDY to indicate that it is awake and polling the SPI interface.
After detecting toggling on DRDY, the host asserts CS and enables SCLK.
The module detects SCLK, enables the SPI interface, and sends a +STARTUP message, indicating readiness for AT commands over SPI.
However, in my case, I do not see any toggling on the DRDY pin during boot. Instead, I directly pull CS low, send the packet (BA, 15, 00, 04, 01, 02, 03, 04), and read the response.

The received packet still shows a corrupted payload:
BA, 15, 0F, 4F, 55, 50, D2, A4, 73.

Additionally, I am sending and receiving data every second task. While the header format appears correct, the payload corruption persists.

Could you confirm if my approach is correct? Do I need to ensure the DRDY pin toggles before proceeding with SPI communication? Also, should I send some dummy data initially to enable SCLK before reading the packet to receive the +STARTUP message?

BR

Nithin

[Harry_Zhang]

Hi @nithin3200 

Based on your description above,

"Do I need to ensure the DRDY pin toggles before proceeding with SPI communication?"

Yes, ​Even if unused, the DRDY pin is essential for proper initialization.

DRDY toggling is essential before starting SPI communication. Since you do not see DRDY toggling, the module may not have fully initialized or is not ready to communicate.

Try toggling the NINA-W132 RESET pin (if accessible) and monitor DRDY again.

BR

Harry

[nithin3200]

Hi Harry,

Thanks for your suggestion. As per your advice, I toggled the RESET pin, and I observed that the DRDY pin starts toggling. However, when I stop toggling the RESET pin, the DRDY pin also stops toggling.

Is this expected behavior, or does it indicate an issue with initialization? Do I need to continuously toggle the RESET pin to keep DRDY active, or should DRDY remain toggling after a single reset

[Harry_Zhang]

Hi @nithin3200 

You should not need to continuously toggle the RESET pin to keep DRDY active. I think that’s definitely not expected behavior.

On power-up or after asserting RESET, the NINA-W132 should perform its internal initialization.

After releasing RESET, the DRDY pin should start toggling to indicate that the module is awake and polling the SPI interface.

BR

Harry

[nithin3200 · Accepted solution]

Hi,

I am now observing continuous toggling of the DRDY pin after a single RESET (low to high). After this, I sent an invalid byte and then read back, which resulted in seeing clock pulses as expected.

However, I am not receiving the expected startup message; instead, I am getting garbage values

.