Discover Wi-Fi Module SPI Communication

Hmm... so I've run into another issue. The module is not replying reliably if I set the baudrate prescaler lower than 64. Not a grounding issue as I connected the grounds on the 2 boards. Shouldn't be a floating voltage issue either as I have the SPI pins in push/pull and pulldown mode. What else could it be?

Does the WiFi have a chip select? It may need to be set low when it is supposed to listen if it is "bar over CS".

Sorry, but I don't quite follow. Pretty sure it doesn't have whatever you're talking about though.

EDIT: OH! Slave select, yes it has that, but I've tied it straight to ground so it's pulled low. Got confused by the term "chip select."

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?

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.

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 ?

MK

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.

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.

MK

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.

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