How to use the SOCKDW command correctly over SPI on SPWF04SA?

Pascal Zosso · ‎2017-12-04

Posted on December 04, 2017 at 09:10

Hello everybody,

Since the release of the new documentation (Datasheet V5 and Command Guide V2), I'm looking for more detailed informations about SPI interface, SPI timing and SPI dialogue.... but the new doc is still poor in informations about SPI (really poor).

After lot of trial, I could send a SOCKDW on my SPI:

02 00 0F 4A 03 01 00 01 00 01 07 AA AA 03 DF 01 01 1F

It means : SOCKDW, sid=0, cid=0, len=7, data isAA AA 03 DF 01 01 1F

After that, I receive the two following reply from SPWF04SA:

02 3A 00 00 00

which I think is a'OK result code' as mention in Command Guide page 14 (see chapter 6.1)

and

02 3A 21 00 00

which I don't know what it is.... because it is not documented....

So my question is double :

Could we have a proper documentation about the SPI interface (sync reply, dialogue sample, )?

and

What does the '02 3A 21 00 00' means?

PS: I really appreciate the new example for SPI protocol but the Second example has still its length false and the text about the translate procedure still contains wrong informations about the byte number.

PSPS: the SPI dialogue for SOCKDW in attachment

[EDIT 2018] I add a SOCKDW example

#sockdw #spi #spwf04

Note: this post was migrated and contained many threaded conversations, some content may be missing.

Gerardo GALLUCCI · ‎2017-12-04

Posted on December 04, 2017 at 14:09

Into UM2114, rev2, I see (page 12) an example on SOCKW command.

Please note that '0' and '5' means 0x30 and 0x35 (not 0x00 and 0x05).

There is not a big difference between AT-commands and SPI protocol. You can easily build your own SPI parser, starting from AT-commands.

Pascal Zosso · ‎2017-12-04

Posted on December 04, 2017 at 17:12

There is not a big difference between AT-commands and SPI protocol. You can easily build your own SPI parser, starting from AT-commands.

It is what I do now, it would be easier if I had the translate of the synchronous replies of SPWF04 over SPI. I found some of them in the training lab but only the 'UART format'.

What I really need to know is what are these synchronous replies on SPI:

AT-S.OK 02 3A 00 00 00 correct?

AT-S.Reading:5:5 02 3A FE 05 00 35 3A 35 0D 0A correct ?

AT-S.ON:0 .....

etc...

To confirm my parser is good, I need to understand what the SPWF04 replies mean.

Into UM2114, rev2, I see (page 12) an example on SOCKW command.

Please note that '0' and '5' means 0x30 and 0x35 (not 0x00 and 0x05).

Yeah, I have seen it and deal with the ASCII char to put the right socket server id, socket client id and data length in the SOCKDW command.

Gerardo GALLUCCI · ‎2017-12-04

Posted on December 04, 2017 at 18:33

I assume you are still using old FW1.0.0 (CrLf inside the packet...)

'02 1* X other' means +WIND ASync messages number X

'02

2

*

X

other

' means critical

+WIND ASync messages number X (module will reboot)

'02 3* Y

other

' means

Sync messages (AT-S.something)

About Sync messages:

'Y == 0xFF' means AT-S.something that cannot be masked (your 'On')

'Y == 0xFE' means AT-S.something that can be masked by console_verbose variable (your 'Reading')

'Y == 0x00

' means AT-S.OK

'Y == Z

' means AT-S.ERROR number Z ( where: 0 < Z < 120 )

Pascal Zosso · ‎2017-12-04

Posted on December 04, 2017 at 19:14

Yes, I use the FW1.0.0. Sorry, I didn't say it.

Thanks for the informations, it is good to know.

Could you tell me if the procedure (in the reply) in this post:

https://community.st.com/0D50X00009XkXVJSA3

also applies to SOCKDW command, it seems to me the author had the same problem as me.

If his procedure is correct, it could explain some problems I have too.

Best regards

Gerardo GALLUCCI · ‎2017-12-04

Posted on December 04, 2017 at 22:20

SPI management has been changed a little bit since that old FW version. I suggest to move into FW1.1 and start from this newer version.

If I'm not wrong, that old FW required master to wait till module put nHostInt low (a kind of flow control...). Something like:

- master: CS low

- master: tx command w/o payload

- master: wait module's 'ready'

- module: nHostInt low

- master: tx payload

...on...

Pascal Zosso · ‎2017-12-05

Posted on December 05, 2017 at 08:46

Ok, your answer confirm what I record on my board.

And it is really, really bad for my application because the Master can not wait that the module is ready to continue to work.

It is mandatory that the Master can send TX command and TX payload in one frame whitout waiting.

It will take time to move into FW1.1.0 and I have to be sure that is worth it.

Before I try to upgrade, could you inform me about these features on FW1.1.0:

- the Master doesn't need to wait module is ready between TX command and TX payload when the Master issue a SOCKDW, right?

- screenshots of SOCKDW and SOCKDR command over SPI to see how it works in new version

Thank you for your help

Gerardo GALLUCCI · ‎2017-12-05

Posted on December 05, 2017 at 10:37

Reference master implementation is into WIFI1 package (for STM32 as external host):

- WIFI1 v3.0.2 + SPWF04 v1.0.0 >>> wait for nHostIRQ between command and payload

- WIFI1 v3.1.0 +

SPWF04 v1.1.0 >>> no more wait

Pascal Zosso · ‎2017-12-05

Posted on December 05, 2017 at 11:33

Thank you, it gives me confidence to do the upgrade process. I will mark the subject as answered as soon as I upgrade and test it.

Pascal Zosso · ‎2017-12-07

Posted on December 07, 2017 at 15:39

So, the upgrade goes well but does not solve the SOCKDW issue as you can see on the picture:

I don't understand why I have an interrupt and 00s after I send my command and the payload. It cause bad behaviour in my application and stuck it.