Discover Wi-Fi Module SPI Communication

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Wed, 18 Feb 2015 22:08:23 GMT

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.

Attachments:

community.element14.com/.../SPI_5F00_FullDuplex_5F00_ComDMAsmplMurata.zip

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Wed, 18 Feb 2015 16:58:12 GMT

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.

RE: Discover Wi-Fi Module SPI Communication

clem57 — Wed, 18 Feb 2015 16:51:33 GMT

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.

RE: Discover Wi-Fi Module SPI Communication

clem57 — Wed, 18 Feb 2015 16:42:09 GMT

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

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Wed, 18 Feb 2015 16:32:44 GMT

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?

RE: Discover Wi-Fi Module SPI Communication

clem57 — Wed, 18 Feb 2015 16:20:26 GMT

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

RE: Discover Wi-Fi Module SPI Communication

clem57 — Wed, 18 Feb 2015 16:19:26 GMT

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

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Wed, 18 Feb 2015 15:27:06 GMT

Not that I am aware of.

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

RE: Discover Wi-Fi Module SPI Communication

clem57 — Wed, 18 Feb 2015 15:18:24 GMT

@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

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Wed, 18 Feb 2015 12:42:48 GMT

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!

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Mon, 16 Feb 2015 19:41:29 GMT

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

RE: Discover Wi-Fi Module SPI Communication

michaelkellett — Sun, 15 Feb 2015 16:00:38 GMT

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.

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Sat, 14 Feb 2015 00:15:23 GMT

"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.

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Thu, 12 Feb 2015 12:53:25 GMT

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.

RE: Discover Wi-Fi Module SPI Communication

michaelkellett — Thu, 12 Feb 2015 08:10:45 GMT

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).

RE: Discover Wi-Fi Module SPI Communication

clem57 — Thu, 12 Feb 2015 05:06:31 GMT

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

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Thu, 12 Feb 2015 04:35:50 GMT

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.

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Wed, 11 Feb 2015 21:53:27 GMT

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.

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Wed, 11 Feb 2015 21:32:16 GMT

I'll reiterate that I have NSS grounded and that seems not to be causing any difficulty.

Here are a couple other things I've done.

1) This app will only turn on the SN8200 when needed so the first step in the sequence is to drive the reset line and release it (low then high.) The code then waits for the GEN_PWR_UP_IND_RSP, When this comes it copies the sequence number from the incoming message and sets the outbound sequence to be 1+ that. This message comes in about 840 msec or it does not come at all. If it does not arrive (presently 10s timeout), the app goes through the reset process again.

2) I have increased the SPI baud rate prescaler to 32. That seems to cause the SN8200 to respond to some messages that previously got no response. I may slow it down further.

3) I have coded back to back receives that only get interrupted when there is something to send at which time the code ussues a send/receive. Hopefully no incoming messages will be lost.

At present the device seems to be inconsistent. I am surprised that the host does not receive power up message 100% of the time following reset.

I tried using the /ALRT input and it seems to be low all the time. (I have not scoped it, just looking at it with a voltmeter.)

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Wed, 11 Feb 2015 21:27:32 GMT

The ALRT pin never seems to go low anymore, so I can't make it clock out only when it's ready. I'm not going to be able to debug this for a while, as it turns out that logic analyzer I linked to previously ships from China, and it's going to cost so much to ship it that I'd probably be better off just getting a Saleae logic analyzer. Unfourtunately, I don't have the money to spend on either right now, so there's not much I can do. Might look into going to a hackerspace later.

RE: Discover Wi-Fi Module SPI Communication

michaelkellett — Wed, 11 Feb 2015 11:25:58 GMT

Before you spend your money why not at least try to code it so that your waveforms look exactly like those on the data sheet ?

And try clocking data out only when it's ready.

These things might not make any difference but they won't cost you anything either.

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Wed, 11 Feb 2015 09:35:57 GMT

The documentation (text, not diagrams) actually seems to suggest that NSS is just a slave select, not a framing signal. It also indicates that using ALRT is optional, and it's fine to just clock data out of the module at any time. I don't see any reason for it to work fine at low baud rates but not high baud rates. I've also verified that the data in the reply is correct... except when it isn't, due to some sort of random data corruption (probably also caused by whatever is making it not work at high baud rates). I think I might be stuck with no choice but to buy a logic analyzer, and look at what exactly is happening on the pins.

RE: Discover Wi-Fi Module SPI Communication

michaelkellett — Wed, 11 Feb 2015 09:04:13 GMT

Some thoughts which may help:

SPI is not implemented in a standard way so the Murata module may or may not take note of NSS or SS.

However it is normal to use NSS as a framing signal, it is much more than just a chip select for multiple slaves.

The SyChip document "Serial Interface Specification", page 13 shows that NSS is used as a framing signal for each byte.

On page 23 of 'SN820X Wi-Fi Network Controller Module Family Data Sheet Version 2.2 February 28, 2014' there is a detailed SPI timing diagram which bothers to specify NSS setup and hold times and a whole load of other stuff. Your first check when things don't work quite right is that you are meeting ALL these limits. Some of them may not matter but you have no way of knowing which ones.

You should send a command, check the state of ALRT/ and clock the data out of the SN82xx chip only when it has asserted ALRT/.

There seem to be plenty of ways to upset the chip by protocol errors - are you using ACK ?

RE: Discover Wi-Fi Module SPI Communication

e14 Contributor — Tue, 10 Feb 2015 23:40:12 GMT

No, I'm currently not bit banging. NSS has nothing to do with this, considering plenty of other people have just tied it to ground and it worked. Like I said, I'm getting replies but not reliably at high baud rates. NSS only matters when controlling multiple slaves from a single master, and in this case I only have one slave.

RE: Discover Wi-Fi Module SPI Communication

clem57 — Tue, 10 Feb 2015 23:34:50 GMT

If you look at the datasheet on this board, they may give a diagram that says when the CS is high or low in relationship to the clock. The timing of when these change is important. Are you bit banging?