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.

Hmm, wasn't aware the sequence number actually mattered, it's not very well documented. Should I be including the "| 0x80" in the checksum as with the UART or not? And as for the ALRT pin, that is pin 17 on J6 by default.

Hi Jordan,

My recollection is that the SN8200 would not reply to subsequent messages with the same sequence number, perhaps programmed to ignore those as the reply had already been sent.

As far as the checksum, the spec says:

Checksum: sum of L0, A | L1 and command ID. Note that this is different from the UART frame where the checksum calculation includes the payload field.

It seems like bit 7 is not included. OTOH their example just below that states:

After SPI serial protocol frame encapsulation, the payload becomes the following SPI frame:

02 83 80 D0 04 33 00 D3 04

02 -- SOM

83 80 -- Payload length (3 octets, excluding CMD_ID)

D0 -- 0x80 | CMD_ID_WIFI

04 -- WIFI_GET_STATUS_REQ

33 -- Sequence number

00 -- STA interface

D3 -- Checksum for “83 80 D0”

04 -- EOM

My calculator says that 83 80 D0 sums to 0x1D3. Lop off the high order bits and that becomes 0x53. So I guess they do include those.

Thanks for the info on the /ALRT pin.

No matter what I try I can't seem to receive anything, unless I set the SPI speed fast enough, then it starts receiving garbage. I've uploaded the correct firmware to the SN8200. Pins 20, 18, 16 and 14 on J6 are the SPI pins, right? I tried 2, 4, 6 and 8 originally but that did nothing at all.

I'm using J6 12, 14, 16, 18 and 20 too. I thought I was having difficulty with NSS (20) so I just tied it to ground. On SPI4 (STM32F429I-Discovery) any baud rate prescaler from 4 through 128 works (don't recall if I tried 256.)

At times the Murata stops sending replies. Some times that is resolved using the reset pin/button and at other times it may require a power cycle. It also doesn't like to be hammered by requests. I had to add a 50ms interval between exchanges.

Well I think I'm getting actual responses now, but I can't verify the data, nor can I seem to clock the response out of the SPI. I have a circular DMA running with an empty buffer to keep the master clock going, but it doesn't seem to be doing anything. Can you check the code? I honestly don't think I know what I'm doing, pretty new to this thing...

C file: https://gist.github.com/b987bbc998b0d27292af

Header file: https://gist.github.com/579f9b3b8b42fb5adc7d

There's a lot of commented out stuff, from various attempts to get the thing to work.

I'll try to take a look at it tonight. It is unlikely I'll see anything as I started working with example code which I modified to suit my needs. ASll of the SPI and other setup was already in place. (In other words, probably know less about it than you.)

Can I see your current code? I could probably figure out what I'm doing wrong by looking at it myself. I can't find the example code you're speaking of.

Sorry - no can do.

Why not exactly? And can you point me to where you got the example code you used?

I started with C:\STM32Cube_FW_F4_V1.4.0\Projects\STM32F429I-Discovery\Examples\SPI\SPI_FullDuplex_ComDMA, part of the package downloaded from STM32CubeF4 Embedded software for STM32 F4 series (HAL low level drivers, USB, TCP/IP, File system, RTOS, Graphic - comi….

I started with C:\STM32Cube_FW_F4_V1.4.0\Projects\STM32F429I-Discovery\Examples\SPI\SPI_FullDuplex_ComDMA, part of the package downloaded from STM32CubeF4 Embedded software for STM32 F4 series (HAL low level drivers, USB, TCP/IP, File system, RTOS, Graphic - comi….

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?