Discover Wi-Fi Module SPI Communication

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