Using the SPWF04S SPI interface

[Ian Taylor]

Posted on May 02, 2017 at 19:16

I am attempting to use the SPI interface of the SPWF04S module but with very limited success

I can get the module out of RESET with the SPI interface enabled by simply pulling the interrupt pin high as the reset pulse ends. The module sends some WIND messages that all make perfect sense. I get 'console active' 'wifi hardware started' etc etc and eventually it settles down to doing scans every few seconds ( I get 'scan active' followed by 'scan complete' repeatedly) That's all good.

I can't get the module to respond to any commands I send it. Lets say I want to send the simplest command (AT) just to determine if the console is alive... Here is what I've tried so far

1- SET CS low ... Send 0x02, 0x00, 0x02, 0x01, 0x00 ... Set CS high ... Wait for INT to go low ... Read response

2- SET CS low ... Send 0x02, 0x00, 0x02, 0x01, 0x00 ... Leave CS low ... Wait for INT to go low ... Read response

3- 

SET CS low ... Send 0x02, 0x00, 0x02, 0x01, 0x00 ... continue clocking

 ... Wait for INT to go low ... Read response

4- 

SET CS low ... Send 0x02, 0x00, 0x02, 0x01, 0x00 ... continue clocking

 ... Wait for sync (0x02) ... Read response

The 'length' bytes are ordered as in the examples in the TCP stack manual (high byte first) but I have also tried all of the above with the two bytes reversed (low byte first, as is the byte order of the receive transactions) but to no avail.

In both cases, if INT does eventually go low, it is not the kind of response I am expecting, just another WIND (usually the next 'scan started' or 'scan complete')

I've been through the manual, the very short section on SPI isn't much help (looks like I should be doing as 1- above (since it shows CS going high at the end of the transaction) but then it's description of the multiple receive isn't what I'm seeing (I see INT go high after every transaction, not staying low as in the manual) and the broken-english description of the SPI transactions don't match either. I'm not sure how far I should trust these diagrams. All of the code examples have sections relating to SPI but on closer inspection, they all use the UART.

Can someone point me in the right direction here with either an accurate description of the transfers or timing diagrams or some example code that actually uses the SPI interface. I've been battling with this for the last 3 days so any help would be greatly appreciated.

Many thanks

Ian

[Gerardo GALLUCCI]

Posted on May 03, 2017 at 10:38

Hi Ian,

did you try the reference code provided by 

http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-software/x-cube-wifi1.html

 package?

[Ian Taylor]

Posted on May 03, 2017 at 12:28

Hi Gerado

Yes, I've had a good look through the X-cube code but I'm not developing on STM32 (hoping eventually to be largely cross platform) so cannot use this directly. I had considered buying the required eval boards and simply scoping the pins to see what's going on but unfortunately none of our suppliers  stock the 

https://my.st.com/content/my_st_com/en/products/ecosystems/stm32-open-development-environment/stm32-nucleo-expansion-boards/stm32-ode-connect-hw/x-nucleo-idw04a1.html

 due to 'US government Export Restrictions', Any ideas how I could get one of these in the UK? All the usual suspects RS, Onecall, Mouser etc. - no luck

Furthermore, I want to be sure that I am getting the boot sequence absolutely correct (all the required GPIOs at the correct levels) to start the SPI interface. Although it stars sending WINDs most of the time, there are always some that are unsynced immediately after boot and one looks like it is pointing to a hardware config problem. WIND ID 0x07 ( Configuration failure ) and 10\r\n in the payload. Looking at the TCP stack manual that is:-

10. (Does not Halt) Shown when HW pull-up resistor has no match with enabled interface

Any ideas which pin / pins this is referring to?

I'll keep hacking away at it today and post again if I make any progress.

[Gerardo GALLUCCI]

Posted on May 03, 2017 at 13:42

About X-NUCLEO-IDW04A1 availability, you can use an EU distributor. I'll send you a private message.

About WIND:7, it's ok. SPWF04Sx default interface is UART (configuration variable console_enabled is 1, meaning 'UART only'). You can enable SPI in HW with pullup on GPIO9, without changing console_enabled variable. To switch this WIND off, change console_enabled to 0 (SPI only).

[Ian Taylor · Accepted solution]

Posted on May 04, 2017 at 16:22

SORTED IT !!!!!!!!!

Thanks to everyone who has had input into this, I've now got it working

It turned out to a be problem with the SPI clock polarity / phase. It appears that the module samples the incoming data on the rising edge of the clock, not the falling edge as shown on Figure 4 of the manual. Thus, the data changes at the falling edge or thereabouts. My MOSI data was phase shifted half a clock to the right. On the PIC32 I'm currently using that meant that I had to set the CKE bit in the SPI configuration register

See the attached image of the start of a WIND notification...

Yellow trace = MOSI - 0x02 0x00 .....

Blue trace = CLK (only 50kHz on the image but now running at 12MHz)

Purple trace = MISO - 0x02 0x14 .....

Green trace CS

Hope someone else will find this snippet if info useful

Ian

________________ Attachments : correctSPI.JPG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hygl&d=%2Fa%2F0X0000000bAx%2FplvifCZI0PBTNThn9O0RSKOey3vL5oAOKtUU0wKJ_TE&asPdf=false

[Gerardo GALLUCCI]

Posted on May 04, 2017 at 16:57

Ciao Ian,

clock line on figure 4 is wrong. Thanks for feedback. We will update that picture.

[Gerardo GALLUCCI]

Posted on May 12, 2017 at 10:58

Also figures 5 & 6 needs to be updated: IRQ is high (because of external pullup), triggers on falling edges, and SYNC word (0x02) coming from SPWF04S is on MISO line (not the MOSI one)

[Matti Sillanpaa]

Posted on June 14, 2017 at 09:26

Hi Ian.

So did you set CPOL = 0 and CPHA = 0 In SPI_CR1? Or what do you mean with CKE bit? I'm using F469.

[Gerardo GALLUCCI]

Posted on June 14, 2017 at 17:33

Probably CKE is something related to 

PIC32.

On STM32 it's CPOL=0 (SPI_CPOL_Low) and CPHA=0 (SPI_CPHA_1Edge)

[Rakshith KR]

Posted on February 07, 2018 at 07:22

Hi GG,

I am working on data logger application for parking solutions,

Even i am trying to interface through spi, and i have updated to latest Firmware SPWF04S-171117-0328fe3-Full

When i power ON the spwf04sa, the first byte sequence is  0x02, 0x02, 0x16, 0x07,0x02.......

i have few queries if you can help me out, 

1. The 3rd and 4th byte is 0x07, 0x02 which is payload length, so what is the total payload length in my case...

    i am really sorry for the silly doubt...

2. When i send the a command should i wait for the IRQ to start receiving the data or should i immediately poll for the data from the SPI buffer.

 3. when i receive the IRQ, should i de-assert it before polling the data...?

4. It is sometimes trick in IRQ pin, i believe i should poll the data when the IRQ goes from high to low from above understanding...

Many thanks in advance....