Discover Wi-Fi Module SPI Communication

I've configured more SPI links than I care to remember and I would never attempt it without  a scope. About half the time it just works and the other times you forget a clock enable or leave a pin in the wrong mode or whatever.

Which development environment are you using ?

I use Keil which allows you to look at the registers of all the peripherals to make sure that they are all set up right.

If you are using Keil I can give you some detailed suggestions - if not you may get better help from someone familiar with the tools you are using.

If all else fails (and it does quite often) - get the link working using code to bit bang the spi link on the uP side ( this is much easier to debug with primitive tools because you can single step everything and use a DMM or even an LED and a  resistor as your logic analyser).

Once it bit bangs then try using the SPI peripheral on the uP

And only once that works should you attempt using DMA.

I very rarely find the problem by looking at the code - you need to step though it and see what actually happens on the pins.

MK

Well I did fix one problem, but it still isn't working. I had the MISO pin set to no pull instead of pull down which was causing it to be floating when low, resulting in erratic behavior (random bits when even so much as touching the wire). I'm using Eclipse as my IDE and OpenOCD to communicate with the on-board ST-Link/V2. I don't see any reason why the SPI wouldn't be clocking out data, as I was able to get I2S working on the external DAC. I tried connecting the other set of SPI pins, and it seems that the MISO on that one is high, but it never goes low when I clock data in/out. All I'm receiving is logical ones. I connected the SPI outputs on the STM32F4 to an input setup with an interrupt to toggle an LED, and that seems to be working fine. I don't think bit-banging the Wi-Fi module will make a difference if the SPI output is working as it should. As I said I couldn't get the UART interface to work either. I'm starting to wonder if the module is somehow damaged. Scratch that, the UART wouldn't work because I messed up a clock enable call.

EDIT: I'm starting to wonder if the SPI interface isn't enabled and I need to upload different firmware. I've been trying to do that but can't find the "boot" pin on the headers.

So it seems that by completing disabling the NSS pin on the STM32F4, it is actually working now. Next step is to ensure the data is correct. I'm also wondering if your "stops sending replies at times" has something to do with an oversight in sequence number. You said it won't reply to a previously used sequence number right? Maybe it overflows back to 0 and no longer works, effectively limiting you to 256 messages to the module before needing a reset. Only a theory though, haven't tested it yet.

EDIT: Just tested it, it continues to reply even after the sequence number wraps around. Strange why it sometimes stops replying for no reason.

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.

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.