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.

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

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.

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