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.

Does your debug system allow you to see the STM32Fxxxx peripheral registers in some sort of organised way ?

If not I suggest you use a different development system : the one I know is the Keil MDK (but there are many others) which is completely free to use for projects with up to 32k of code - it does support peripheral debugging.

The point about using bit banging to debug is that you can trace and single step everything - this just isn't possible any other way (although a good logic analyser comes  close.)

Is MISO supposed to be driven by the wIfI module ? From your description of things it looks as if it is not being driven at all. Are you doing all the things to the wifi to enable its SPI that you should ?

MK

I'm currently trying to figure out how to configure the Wi-Fi module correctly for SPI, and yes MISO should be driven by it because it's the slave. I need to put the device in firmware upload mode by driving the "boot" pin high, but I cannot find said pin. Would you happen to have any idea where it is? I'll have to get back to you on the peripheral registers thing, I honestly haven't checked. But I don't think it's a configuration issue as I can get other peripherals to work just fine.

The boot pin on the Murata WiFi chip is referred to on the Murata docs but you can't tell if it is accessible on the Discover board because there is no schematic in the board User Manual - I suggest you moan, very loudly, to Farnell about this  - this kind of board should always be fully documented.

It does (sort of) tell you how to do a firmware upgrade without using the boot pin on page 46 of the board user manual.

MK

Yeah I just found that page and did the firmware upgrade using the SWD on the STM32F4 board. Going to try using the SPI now, will report back.

So I've been mucking around with it for a bit, and I'm consistently receiving weird round values like 0xFF, 0x7F and 0x3F, but not any start-of-message (0x02) or end-of-message (0x04) bytes. It's clearly not just garbage because it's consistent every time I reset the microcontroller. The module also seems to realize it's receiving data because the ALRT pin goes high. However, I changed the baudrate prescaler to 256 and all of this behavior went away, so I'm honestly not sure. I might try the bit-banging, though that's going to take some time to mess around with. I really need to get a logic analyzer and oscilloscope, but can't afford either right now. That would really help with debugging this.

I connected MOSI to MISO on the STM32F4 so it's looping back to itself, and it's definitely sending the right data, so the Wi-Fi module just doesn't seem to be communicating over SPI. I configured it to use SPI and uploaded the edited firmware, so I'm honestly stumped. Using a BaudRatePrescaler lower than 64 still causes the STM32F4 to receive the consistent "garbage" from the module.

I connected MOSI to MISO on the STM32F4 so it's looping back to itself, and it's definitely sending the right data, so the Wi-Fi module just doesn't seem to be communicating over SPI. I configured it to use SPI and uploaded the edited firmware, so I'm honestly stumped. Using a BaudRatePrescaler lower than 64 still causes the STM32F4 to receive the consistent "garbage" from the module.

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?