Skip to main content
Ian Taylor
Ian Taylor
Associate
May 2, 2017
Solved

Using the SPWF04S SPI interface

  • May 2, 2017
  • 4 replies
  • 2663 views
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

    This topic has been closed for replies.
    Best answer by Ian Taylor
    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

    4 replies

    Gerardo GALLUCCI
    Gerardo GALLUCCI
    ST Employee
    May 3, 2017
    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
    Ian TaylorAuthor
    Associate
    May 3, 2017
    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
    Gerardo GALLUCCI
    ST Employee
    May 3, 2017
    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
    Ian TaylorAuthorAnswer
    Associate
    May 4, 2017
    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
    Gerardo GALLUCCI
    ST Employee
    May 4, 2017
    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
    Gerardo GALLUCCI
    ST Employee
    May 12, 2017
    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)

    Richard Bene¨
    Richard Bene¨
    Associate
    April 16, 2018
    Posted on April 16, 2018 at 13:02

    I had exactly the same issue, however SPI parameters correctly.

    Few hours I've struggled with non-answering SPWF04, until I tried to set higher SPI clock (someone on this forum wrote that 4Mb/sec didn't work properly, 8Mb/sec did).

    After that, SPWF04 started to answer.

    So if someone has similar issues, ~325Kb/sec is too low clock. At 10.5Mb/sec it works.

    I don't know where exactly the limit is.

    Hope this helps someone.

    R. Beneš

    Terms & ConditionsAccessibility statement