cancel
Showing results for 
Search instead for 
Did you mean: 

SPWF04SA DHCP Server problem

bernd sch�nlebe
Associate II
Posted on August 01, 2017 at 11:31

I have setup the module as miniAP with following script: (

http://elektronikab2b.pl/technika/32973-spwf04sa-miniaturowy-modul-wi-fi-z-oferty-stmicroelectronics---przyklady-zastosowan

)

AT+S.WIFI=0

AT+S.FCFG

AT+S.SSIDTXT=test_ap

AT+S.SCFG=wifi_priv_mode,1

AT+S.SCFG=wifi_mode,3

AT+S.SCFG=wifi_wep_keys[0],76543210ab

AT+S.SCFG=wifi_wep_key_lens,05

AT+S.SCFG=wifi_auth_type,0

AT+S.SCFG=ip_ipaddr,192.168.0.1

AT+S.SCFG=ip_use_dhcpc,2

AT+S.WIFI=1

AT+S.WCFG

AT+S.RESET

once it restarts, this is what I get:

Port opened

SPWF04SA WIFI test program start.

Setup SPI done.

Reset module...

Start module...

Done.

RX:02 10 07 02 00 AT+S.WIND:7:Configuration Failure:<wifistate=Hardware power up>:10

RX:02 10 01 16 00 AT+S.WIND:1:Poweron:<wifistate=Hardware power up>:170726-b7ac1ba-SPWF04S

RX:02 10 0D 08 00 AT+S.WIND:13:Copyright:<wifistate=Hardware power up>:SPWF04SA

RX:02 10 03 02 00 AT+S.WIND:3:Watchdog Running:<wifistate=Hardware power up>:20

RX:02 10 00 00 00 AT+S.WIND:0:Console active:<wifistate=Hardware power up>:

RX:02 13 20 00 00 AT+S.WIND:32:WiFi Hardware Started:<wifistate=Radio idle>:

RX:02 13 1A 07 00 AT+S.WIND:26:Started AP:<wifistate=Radio idle>:test_ap

RX:02 19 18 0D 00 AT+S.WIND:24:WiFi Up:<wifistate=802.11 handshake complete>:0:192.168.0.1

RX:02 1A 18 1C 00 AT+S.WIND:24:WiFi Up:<wifistate=Ready to TX>::fe80:0:0:0:280:e1ff:febd:39

now, just to be sure, here the entire config printout:

TX:02 00 02 09 00 //AT+S.GCFG

nv_manuf=STMicroelectronics Inc.

nv_model=SPWF04SA

nv_serial=17111984

nv_wifi_macaddr=00:80:E1:BD:00:39

standby_time=10

standby_enabled=0

sleep_enabled=0

etf_mode=0

blink_led=1

ext_volume=3

ramdisk_memsize=16

aes128_key=00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

user_desc=anonymous

python_script=3:/uPython_test.py

python_memsize=32

console_enabled=1

console_speed=115200

console_hwfc=0

console_echo=1

console_errs=2

console_winds=2

console_verbose=1

console_repeater=0x21

console_delimiter=0x2C

console_wind_off_low=0x00000000

console_wind_off_medium=0x00000000

console_wind_off_high=0x00000000

wifi_tx_msdu_lifetime=0

wifi_rx_msdu_lifetime=0

wifi_operational_mode=0x00000011

wifi_beacon_wakeup=1

wifi_beacon_interval=100

wifi_listen_interval=0

wifi_rts_threshold=3000

wifi_ssid=74:65:73:74:5F:61:70:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

wifi_ssid_len=7

wifi_txfail_thresh=5

wifi_dtim_period=1

wifi_add_tim_ie=0

wifi_region=1

wifi_ht_mode=1

wifi_channelnum=6

wifi_opr_rate_mask=0x003FFFCF

wifi_bas_rate_mask=0x0000000F

wifi_mode=3

wifi_auth_type=0

wifi_atim_window=0

wifi_powersave=0

wifi_tx_power=18

wifi_rssi_thresh=0

wifi_rssi_hyst=0

wifi_ap_idle_timeout=120

wifi_beacon_loss_thresh=10

wifi_priv_mode=1

wifi_wep_keys[0]=76:54:32:10:AB:00:00:00:00:00:00:00:00:00:00:00

wifi_wep_keys[1]=00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

wifi_wep_keys[2]=00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

wifi_wep_keys[3]=00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

wifi_wep_key_lens=05:00:00:00

wifi_wep_default_key=0

wifi_wpa_psk_raw=00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

wifi_wpa_psk_text=

wifi_eap_identity=identity

wifi_eap_anon_identity=anonymous@identity.org

wifi_eap_passwd=password

wifi_eap_type=0

wifi_eap_skip_datechecks=0

wifi_wps_walk_time=120

wifi_wps_pin=1234567

ip_sock_memsize=1

ip_sock_threshold=0

ip_dhcp_lease_time=120

ip_macfilter=00:00:00:00:00:00

ip_num_clients=5

ip_allow_port_scans=1

ip_use_v6=1

ip_use_dhcpd=1

ip_use_httpd=1

ip_use_tftpd=1

ip_use_dhcpc=2

ip_hostname=iwm-BD-00-39

ip_apdomainname=captiveportal.net

ip_apredirect=firstset.html

ip_ipaddr=192.168.0.1

ip_netmask=255.255.255.0

ip_gw=192.168.0.1

ip_dns1=192.168.0.1

ip_dns2=208.67.220.220

ip_local=0:0:0:0:0:0:0:0

ip_dns1v6=0:0:0:0:0:0:0:0

ip_dns2v6=0:0:0:0:0:0:0:0

ip_dhcp_timeout=20

ip_ntp_server1=ptbtime1.ptb.de

ip_ntp_server2=ntp0.ipv6.fau.de

ip_ntp_refresh=3600

ip_ntp_startup=1

ip_mdns_domain_name=SPWF04S-Default

ip_mdns_device_name_ttl=120

ip_mdns_services_name=SPWF04S-WebSrv SPWF04S-TFTPSrv

ip_mdns_services_prot=_http._tcp _tftp._udp

ip_mdns_services_keys=dev1 dev2

ip_mdns_services_vals=number1 number2

ip_mdns_services_port=80 69

ip_mdns_services_ttl=120 60

ip_mdns_startup=01:01

now my problem is this: once I try to connect with my phones wifi f.e., it does recognize that a station gets associated, but it does not give out an IP, what do I have to setup for it to work?

RX:02 1A 1C 13 00 AT+S.WIND:28:Station Associated:<wifistate=Ready to TX>:00:16:EA:E5:89:FE:0

RX:02 1A 1C 13 00 AT+S.WIND:28:Station Associated:<wifistate=Ready to TX>:00:16:EA:E5:89:FE:0

RX:02 1A 48 13 00 AT+S.WIND:72:Station Disassociated:<wifistate=Ready to TX>:00:16:EA:E5:89:FE:1

PS: I see the 'Configuration Failure' but its non-halting and I dunno what HW pullup resistor is meant here. This all worked fine before I upgraded the firmware (SPWF04S-170726-b7ac1ba)

PPS: if I downgrade back (firmware SPWF04S-170216-fd39c59), it works but all the fixed problems (with SPI communication) are back, so this has to be a firmware issue

13 REPLIES 13
Elio Cometti
Senior II
Posted on August 10, 2017 at 19:20

Hi,

let me make some comments:

AT+S.WIFI=0  <-- swith off the radio

AT+S.FCFG  <-- load factory configuration in RAM *

AT+S.SSIDTXT=test_ap

AT+S.SCFG=wifi_priv_mode,1

AT+S.SCFG=wifi_mode,3

AT+S.SCFG=wifi_wep_keys[0],76543210ab

AT+S.SCFG=wifi_wep_key_lens,05

AT+S.SCFG=wifi_auth_type,0

AT+S.SCFG=ip_ipaddr,192.168.0.1

AT+S.SCFG=ip_use_dhcpc,2 <-- set DHCP client configuration **

AT+S.WIFI=1  <-- switch on the radio ***

AT+S.WCFG

AT+S.RESET

* Best practice is AT+S.FCFG -> AT+S.WCFG -> AT+S.RESET

** you should enable DHCP server here, by AT+S.SCFG=ip_use_dhcpd,1

*** since you reloaded the factory configuration, this should be moved after AT+S.RESET to take effect of FCFG + new configuration

I would use one of the following instead:

1) reload FCFG and program the radio with new params:

AT+S.WIFI=0

AT+S.FCFG

AT+S.SSIDTXT=test_ap

AT+S.SCFG=wifi_priv_mode,1

AT+S.SCFG=wifi_mode,3

AT+S.SCFG=wifi_wep_keys[0],76543210ab

AT+S.SCFG=wifi_wep_key_lens,05

AT+S.SCFG=wifi_auth_type,0

AT+S.SCFG=ip_ipaddr,192.168.0.1

AT+S.SCFG=ip_use_dhcpd,1

AT+S.WCFG

AT+S.RESET

It might be necessary to wait for WIND:38 after AT+S.WIFI=0

2) program the radio with new params, leaving everything else unchanged:

AT+S.WIFI=0

AT+S.SSIDTXT=test_ap

AT+S.SCFG=wifi_priv_mode,1

AT+S.SCFG=wifi_mode,3

AT+S.SCFG=wifi_wep_keys[0],76543210ab

AT+S.SCFG=wifi_wep_key_lens,05

AT+S.SCFG=wifi_auth_type,0

AT+S.SCFG=ip_ipaddr,192.168.0.1

AT+S.SCFG=ip_use_dhcpd,1

AT+S.WIFI=1

AT+S.WCFG

It might be necessary to wait for WIND:38 after AT+S.WIFI=0.

It might also be necessary to wait for WIND:24 after AT+S.WIFI=1 in order to save the 'radio on' state and have the radio automatically switched on at next reboot.

Posted on August 14, 2017 at 09:35

same result, also the RESET command wants some arguments it seems...

TX:02 00 02 03 00

RX:02 3A 02 00 00 AT+S.ERROR:2:Missing argument(s):<wifistate=Ready to TX>:

here the 3 variants I tried:

https://pastebin.com/R3xTwJqe

https://pastebin.com/LRnSsz7a

https://pastebin.com/MJjD4HMR

Best regards

Posted on August 14, 2017 at 15:56

>  TX:02 00 02 03 00

>  RX:02 3A 02 00 00 AT+S.ERROR:2:Missing argument(s):<wifistate=Ready to TX>:

in the RX stream, 3A means 'incoming data' + 'status 10=Ready to TX', while 02 is the indication message for RESET (it is not an error code).

In other words, it is the reply to AT+S.RESET message. On the UART console you would see WIND:2:Reset

Posted on August 15, 2017 at 10:48

well this is not documented anywhere, also how is this intended to be read? do I read 5 header bytes anyway? shouldnt the module do something afterwards, like restarting? For me it only stops blinking and wont start until I reset it via the reset line (

X-NUCLEO-IDW04A1

CN5, PIN 3 'WAKEUP'), is that so intended? I also attached a wireshark log from the client side (WIN7, TPLink Adapter TL-WN722N), my source code from my arduino, a screenshot of how the pc side looks like (mainly just for byte generation and header decoding) and 2 photos of the module and its jumper location, I hope this helps you debugging

best regards

________________

Attachments :

wifi_dhcp.pcapng.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyVn&d=%2Fa%2F0X0000000b8v%2F0Rd1QPwx5nA0jaXvS8APqxzrAJtsuFaD5C_RgD9ocxA&asPdf=false

wifi_test.ino.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyVd&d=%2Fa%2F0X0000000b8r%2FDtpwo4wWs0sjqbasUp4_zzfdQYqZEDBVQ4opTttX5fk&asPdf=false

front.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyVY&d=%2Fa%2F0X0000000b8q%2F1T3Lk7tEUbpaRLRMYgoUKDTjTnMX2TXNl2vcXPNbxFs&asPdf=false

back.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyVT&d=%2Fa%2F0X0000000b8p%2FePNiaAU4XWs1iHMOpf.L27bfS5T3RKafjd5rcr0ZCNs&asPdf=false

gui.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hy9z&d=%2Fa%2F0X0000000b8o%2FzuUy5JXj65mOJai6eC4kKDXYKBbCaBdvjH.SyjioNVg&asPdf=false
Posted on August 18, 2017 at 17:12

When you issue the reset command then you should expect an answer like for all others commands, so yes, you should wait for INT line low and read the answer.

The reason for the module to not reboot after AT+S.RESET might be the configuration of RSTpin. Please try setting it as

OUTPUT_OPEN_DRAIN instead of OUTPUT.

About the wireshark log, unfortunately it is not useful. The complete traffic is needed to verify if the SPWF04 answers to the Discover frames (that is what we expect) and if the PC is discarding some frame and why.

Posted on August 22, 2017 at 08:30

The reason for the module to not reboot after AT+S.RESET might be the configuration of RSTpin. Please try setting it as

OUTPUT_OPEN_DRAIN instead of OUTPUT.

there is no such thing as

OUTPUT_OPEN_DRAIN

in arduino world, but I solved this issue with following code:

void ResetModule()

{

  digitalWrite(RSTpin, INPUT_PULLUP);

  pinMode(RSTpin, OUTPUT);

  Serial.println('Reset module...');

  digitalWrite(RSTpin, LOW);

  delay(100);

  Serial.println('Start module...');

  digitalWrite(RSTpin, HIGH);

  delay(100);

  Serial.println('Done.');

  pinMode(RSTpin, INPUT);

}

it makes the pin only output for the time it needs to reset the modul (at start or on command) and then reverts it back to an input. now the module starts again after replying with 02 32 02 00 00 (hex) but I guess all it does is toggle that pin itself, no?

About the wireshark log, unfortunately it is not useful. The complete traffic is needed to verify if the SPWF04 answers to the Discover frames (that is what we expect) and if the PC is discarding some frame and why.

what do you mean?! this IS the entire traffic! what am I supposed to record elsewise? this is wireshark recording how a TP-LINK TP-WN722N WLAN stick attempts to connect, there are no packets coming in otherwise, even in monitor mode. I also gave you a log of 3 variants of what the module says over SPI and it clearly sees the station, associates it and then doesnt even tell it send some dhcp reply or got a request. again, when I downgrade the firmware to the old version it all works fine, but then I can not send replys because those spi commands (AT+S.SOCKDW f.e.) need their special format for the appended data (please add this to the datasheet, I only guessed it!) and that doesnt work in the old firmware. So im stuck either way

Posted on September 04, 2017 at 07:27

hello again,

is there any update on this yet? if I dont get this to work, we cant use this in our products

Best regards

Posted on September 04, 2017 at 13:10

Hi.

If you have socket write problem it might be related to same issue i had:

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

The Cube driver assumes only string payload (unlike the old SPWFSA01) and I think the SPWF04 side assumes same thing too. I've heard about revised driver to be upcoming since end of July. Dunno what year though

🙂

.

Posted on September 04, 2017 at 13:21

thanks, but my problem is the DHCP server, I dont even get an IP assigned, it sees, yes someone wants to connect to the AP, (associates it) but no IP is given out (DHCP not doing its job). So no way to get to sockets yet (except ofc I used the downgraded firmware again with all it bugs, like not beeing able to write to sockets). I guess we simply have to look for a module from another vendor, this is not usable in products this way (maybe on the slower UART protocol, but we dont use that if faster SPI exists)

thanks anyway