Discover Wi-Fi Module SPI Communication

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

Not that I am aware of.

The package which can be downloaded from Element14 includes sample code for the UART version.

Not sure of your host, but this seems like a possibility based on gcc toolchain http://www.broadcom.com/products/wiced/wifi/

This http://www.element14.com/community/message/95583/l/wifi-sn8200#95583 led me to the link btw

Hi Clem,

From the discussions I'd seen about WICED I had the impression that it was intended to customize the firmware on the SN8200. Our desire is to use the SN8200 as a peripheral for another system and using the factory firmware on the sn8200 itself. Are you suggesting that WICED can be used to develop S/W to run on another processor (such as a Discovery board) and interface with the sn8200?

Hi Hank,

     From what I can tell Broadcom sold the chip to Murata about 1-2 years ago. So if the firmware should be based on Broadcom then it could already be WICED capable without firmware changes. I do not have this, so you would need to try. I would be interested in the results which ever way you decide to go.

Hope this helps,

Clem

Found it! http://wireless.murata.com/RFM/data/wiced_application_development_with_sn82xx_evk.pdf This PDF shows how to use WICED with the SN8200 board.

Hi Clem,

Thanks for the info and the help. That describes programming the EVB. That's not what we want to do. Our plan is to use the sn8200 (sn8205 actually) as to provide a way for another processor to communicate with a host PC via WiFi. We don't plan to program our application on the sn8200 itself. We thought we could do this by using the published APIs for the sn8200. I have not been entirely successful getting that to work.

Hi Clem,

Thanks for the info and the help. That describes programming the EVB. That's not what we want to do. Our plan is to use the sn8200 (sn8205 actually) as to provide a way for another processor to communicate with a host PC via WiFi. We don't plan to program our application on the sn8200 itself. We thought we could do this by using the published APIs for the sn8200. I have not been entirely successful getting that to work.

For my latest adventure I'm trying to implement the ACK bit in the protocol. It appears that the checksum is calculated differently when that bit is set and the response that I'm seeing is not well formed. I expect 02 80 80 FF FF 04. Instead I see 80 80 FF FF 04. Following the mal-formed ACK there is a normally formed sn8200 reply.

I've attached sample code that demonstrates this (as well as using DMA) with some instructions on how to run it in the README.txt. (and a git repo with code committed before I made any changes.) On my PC this is in C:\STM32Cube_FW_F4_V1.4.0\Projects\STM32F429I-Discovery\Examples\SPI.