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.

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?