Discover Wi-Fi Module SPI Communication

So then I'm not the only one having issues with the device being inconsistent. Good to know. I actually already drive the reset line low then high, though I didn't know about the GEN_PWR_UP_IND_RSP, I just coded a delay. As for lowering the baud rate, the problem with that is I need the high baud rate as I intend on transferring data at several Mbps. According to the docs, the device is supposed to be able to go up to 18.4 Mbps on the SPI interface, so I'm not entirely sure what is going on here. On another note, I found out why the UART interface didn't work. The send code in the UART interface example is botched up so it didn't wait for one byte to finish before sending the next, therefore it lost most of the data.

Found some new info from a discussion on the Broadcom website (SN8200 SPI message format | Broadcom Community). Apparently the device actually only does half-duplex, and will corrupt replies unless you send 0xFF on MOSI while receiving. I haven't tested this yet though.

Ouch! So SPI is defined as possibly full duplex, but "the device actually only does half-duplex". This makes sense because WiFi is a half duplex protocol at present!

Clem

What were you sending on MOSI while receiving ?

The way that SPI works is that for every byte received one is sent and vice versa.

It is very common that you have to deliberately set the contents of the "dummy" byte sent out by the master while you clock in replies.

I'm baffled that both you and Hank are having problems but haven't tried cranking NSS exactly as Murata show it in the timing diagram. (Perhaps Hank has, I can't quite tell from his reply).

MK

To clarify:

(My first effort working in depth with SPI. Other times I've used it with no difficulty.)

I'm using the STM32Cube libraries (*) and started with a SPI/DMA example for the processor board (STM32F429I-Discovery) I copied the example message from the SPI SNIC manual and sent that to the SN8200 and watched for the reply. Eventually got that working by connecting NSS to ground - we will only have one device on this SPI bus anyway. I also found that reducing the baud rate seemed to help. With communication more or less working I can finally work out the logic in my app and perhaps try some other things.

From working with canned messages I moved to code that builds and exchanges "real" messages.

I have access to a Beagle protocol analyzer and may hook that up to see if the 'missing messages' are truly missing or if the host app is somehow just not seeing them.

(*) I'm using the libraries because I have no in depth knowledge about SPI configuration. That's why I refer questions about this to the libraries.

"I'm baffled that both you and Hank are having problems but haven't tried cranking NSS exactly as Murata show it in the timing diagram. (Perhaps Hank has, I can't quite tell from his reply)."

I suppose I have a deeply held belief that holding NSS low the entire time should work. And if it didn't work, it would not work 100% of the time. I see something that seems to be in the vicinity of 50% success rate getting messages back from the sn8200.

But if you have detailed knowledge of this, please share! The diagram shows NSS going low before the first bit is sent and going high before the last bit. Is that the last bit of each byte? The last bit of the entire transmission? I'm not sure I could even accomplish the former w/out bit-banging. (heh, I learned a new term. ) I could do the latter. In that case what is the minimum time between when NSS goes high and low? If I'm running back to back DMA reads and issue the next read as soon as the previous completes, NSS won't be high for very long, no? In that case it might as well be held low continuously.

Unless you know exactly how the logic inside the Murata chip is implemented then some of your questions can't be answered, for example

"NSS won't be high for very long, no? In that case it might as well be held low continuously."

For all you or I know there is some edge triggered thing inside the Murata chip which has to be operated for it to work correctly - I've certainly designed FPGA SPI ports where the rising edge on NSS clears some internal error states in the SPI peripheral - I understand that this is common.

So you need to do exactly what the data sheet says as far as possible.

It is not clear if yout should raise/lower NSS after each byte or not - you'll need to test.

But this section from the serial interface manual is clear enough:

When the SN8200 module has data, it indicates to

the host by asserting a dedicated GPIO line (ALRT/). The signal transitions from high to low to signal the

event, and returns to the high state prior to the completion of the current data transfer. If the host connects

this signal to an interrupt line, then upon receiving the GPIO interrupt, the host may assert NSS and start

clock to initiate data transfer from the module. In the case when the GPIO interrupt pin is not available on

the host, it may assert NSS and send clock periodically to poll data from the module

They obviously expect NSS to be asserted at the start of each read out operation so by implication it must be de-asserted at the end of each.

With regard to timing, while they show MISO from the ls bit persisting until just after NSS goes high they do NOT show this for MOSI, there should be no problem using any reasonable (ST is included) SPI interface.

I would not be using DMA until it was working properly without.

Since Murata don't spec the gap between NSS rising and NSS falling I suggest you play it safe and give it several PCLK times. And make sure you observe tsu(nss) and th(nss)  - which requires you to know the clock speed of the Murata chip.

MK

Hi Michael,

Thank you for your insight into SPI communication. I implemented that, driving a GPIO but with S/W and asserting prior to read/write and de-asserting when complete and it has improved communication considerably. The sn8200 still seems a little wonky. If I disconnect form the AP it seems to have a *lot* of difficulty reconnecting. Once connected however, it reports a good connection about 1 1/2 s following reset. I've recoded the S/W that manages this to not disconnect - just shutdown when not needed. The sn8200 stores connection information in NVM and uses that on the next restart. (I need to see if it stores the shutdown too. Parhaps the code should just pull power or assert reset when WiFi is not needed.

thanks,

hank

Combing through the "SNIC Serial Interface Specification" v2.6 I find a message that the host must send to the SN8200 in response to the WIFI_NETWORK_STATUS_IND message with the SCID WIFI_NETWORK_STATUS_CFM. The value for this SCID is not documented in the file nor can I find it used in any of the example code. It must be important otherwise it would not be described.

What is the correct value for this? Can I guess it is the same as WIFI_NETWORK_STATUS_IND? Maybe WIFI_NETWORK_STATUS_IND|0x80?

thanks!

@hankb

   This document looks like a very low level guide to writing TCP/IP at the socket layer or UDP. Is there another interface that is more high level?

Clem