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.

This is  a bit of  a poser - at this stage I would connect the logic analyser

Are you able to borrow one ?

There might be a  hackerspace or college resource you can access nearby.

Or if you are in South West Scotland ..........

MK

I actually live in the US, in Florida to be more specific. I'm don't know of any place nearby that will have a logic analyzer I can borrow. Got any other ideas?

Nothing nice,

The software only SPI is debuggable but takes a lot of effort and without test gear it's difficult to be sure that it's all working the way it should.

You can buy a  logic analyser for as little as £7.99 from Ebay (these look like Salea knock offs - so you have to consider the ethics and risks).

You can buy a real Salea for $109,

Or you can look for a Hackerpsace

Florida - HackerspaceWiki

MK

What about this logic analyzer? It looks pretty decent and is reasonably priced. I wasn't planning on buying a logic analyzer but I guess I don't have much of a choice. Going to a hackerspace is difficult in this case, since I won't have everything I need to work with the microcontroller.

Prototype: Openbench Logic Sniffer logic analyzer | Dangerous Prototypes

It looks OK and about as cheap as you can get legally.

I've no experience of SUMP but it seems to supported by at least a few active people.

I probably have  a different outlook on these things from you since I do this stuff for a living but I would worry that I might waste more time with the slightly DIY Logic Sniffer than I would doing in software.

It shouldn't take more than a few hours to write  an instrumented bit banging SPI and then you can save your $50 for later.

Another cheap approach would be to make a simple SPI debugger based on an ST nucleo board  (they are pretty cheap).

MK

Ok, I'll try the bit banging. What would I do next after trying that? As I said I'm rather clueless here, I haven't messed with hardware much before as I primarily do software programming, so I'm still kind of learning about this stuff. Plus this is a really strange issue.

You won't need to do anything else because it's bound to work

Actually you need write the bit banging interface so you can use it like a logic analyser. So for each clock edge you need to capture the bus state before and after. You'll need to reserve as big  a memory buffer as you can and stick the samples into that. Then you can read them out via a UART into a PC and process them using in your favorite a language.

The last time I did this in a serious way I used an FPGA to snoop on the SPI bus and wrote software to decode and display it nicely. I was more interested in the traffic at a higher level and in understanding the protocol being used. I had to use the FPGA because I didn't control master or slave. If I had to do the same thing today I could use the logic analyser attache to my scope to capture the basic SPI traffic.

MK

I'm starting to wonder if there's a much bigger issue here. I can't get my USB-to-UART to communicate with the STM32F4, it's only receiving garbage. I made sure the baud rates are matched, and even tried 9600 baud. I'm just receiving 0xFC and 0x4, which is not what I transmitted.

First step is to check that the uP clock is running at the frequency you think.

It's quite easy to get it wrong on the STM32Fxxx range.

Set up a timer to blink an LED - and count the blinks with a watch if you don't have anything that'll measure fast pulses.

In the ST library there is a function called:

Which will try and tell you how all the clocks are set - it makes soem assumptions (like about the speed of the HSE clock) so you need to check these are set correctly.

MK

I already had an issue with the clocks when messing with the external DAC, and I solved that and got it working, so it's definitely not that. Any other ideas?

I already had an issue with the clocks when messing with the external DAC, and I solved that and got it working, so it's definitely not that. Any other ideas?

I was able to get SPI communication working by starting with one of the SPI/DMA examples in the STMCube32 library package and modifying it to send canned messages. There's one in the manual and you should be able to construct others. You will have to vary the sequence number otherwise the module won't reply to subsequent messages. That's easy since the sequence number is not included in the checksum. Also be aware that the protocol is not the same as the UART protocol WRT checksum and escaping so you will not be able to just plug in SPI where UART is used in the example. (And that's aside from the situation that SPI reads complete whether the slave is sending anything or not.)

Not clearly specified above is that you definitely need different firmware to use SPI. You will need to get that from Murata.

I found this thread looking for info on the /ALRT signal described in the Murata manual (SNIC Serial Interface Specification, v2.6, SPI variant.) Is it on one of the Discovery-WiFi pins? Can it be put there using the SyChip SNIC Monitor? (Modify the firmware?)

Thanks!

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?