Discover Wi-Fi Module SPI Communication

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

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.