SPWF01SC.11 send data to Server by TCP Socket.

Posted on March 27, 2015 at 15:42

Hi,

which version are you evaluating?

Can I have a full dump of configuration and status variables?

Thanks, and sorry for the issue!

ciao

jerry

Posted on March 28, 2015 at 02:10

I use firmware 141106 rel 3.3

# Dumping All Configuration Keys:

#  nv_manuf = ST

#  nv_model = SPWF01SC1

#  nv_serial = 1114E11454

#  nv_wifi_macaddr = 00:80:E1:FF:CD:56

#  blink_led = 0

#  wind_off_low = 0x00000000

#  wind_off_medium = 0x00000000

#  wind_off_high = 0x00000000

#  user_desc = anonymous

#  escape_seq = at+s.

#  localecho1 = 0

#  console1_speed = 230400

#  console1_hwfc = 0

#  console1_enabled = 1

#  sleep_enabled = 0

#  standby_enabled = 0

#  standby_time = 10

#  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 = 44:47:53:32: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_ssid_len = 4

#  wifi_channelnum = 6

#  wifi_opr_rate_mask = 0x00003FCF

#  wifi_bas_rate_mask = 0x0000000F

#  wifi_mode = 1

#  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 = 2

#  wifi_wep_keys[0] = 00:00:00:00:00: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 = 00:00:00:00

#  wifi_wep_default_key = 0

#  wifi_wpa_psk_raw = 84:14:B0:82:F3:D3:2E:24:06:9B:CA:BD:16:B9:9D:D0:40:10:F5:C3:AC:D7:3F:57:C2:39:D3:7D:84:D1:C9:38

#  wifi_wpa_psk_text = 445b926b99

#  ip_use_dhcp = 1

#  ip_use_httpd = 1

#  ip_mtu = 1500

#  ip_hostname = iwm-FF-CD-56

#  ip_apdomainname = captiveportal.net

#  ip_ipaddr = 192.168.0.50

#  ip_netmask = 255.255.255.0

#  ip_gw = 192.168.0.1

#  ip_dns = 192.168.0.1

#  ip_http_get_recv_timeout = 3000

#  ip_dhcp_timeout = 20

#  ip_sockd_timeout = 250

Posted on March 30, 2015 at 18:48

Thanks for the dump.

I tried to reproduce the issue, but I had no luck. I'll keep on trying...

I'll suggest you to upgrade to near coming FW3.4, when available. There are important fixes, and improved overall reliability. Stay tuned with your local ST support for FW delivery.

Posted on March 31, 2015 at 03:27

Thank you,

When It is released? I waited for so long.

Sory for my bad English.

Tran Khoa.

Posted on April 02, 2015 at 10:52

I send a buffer ex data[5]={0x01,0x02,0x03,0x00,0x04}

I use command

at+s.sockw=00,5

and send data[5] but module wifi only received 3 byte 0x01 0x02 0x03.It pass from byte 0x00.

Is it a bug? 

Posted on April 03, 2015 at 12:25

Hi,

I try to figure out your use case:

- Your external host sends over UART the AT-command SOCKW(5 bytes)

- Module takes only 3 bytes, and never gives ''OK'' message back to external host

Is it correct?

If you are not using an external host, be sure you are not sending CR and/or LF.

No bug. Let me understand your use case.

Regards

jerry

Posted on April 06, 2015 at 02:49

I use external host (STM32F401VCT6).

It's correct.Module never gives ''OK'' back,It's wait for 2 bytes.It's like this

char data[5]=

{0x01,0x02,0x03,0x00,0x04}

;

printf(''at+s.sockw=00,5\r'');

printf(data);  //Module never gives ''OK'' It's wait for 2 bytes more.

printf(0x02);

printf(0x03); //Module gives ''OK'' here and TCP Sever receives 0x01,0x02,0x03,0x02,0x03

Posted on April 07, 2015 at 09:35

Hi,

since a long time I tried with different STM32Fx and STM32Lx and others, and I never experienced a behavior like this.

I always use also PC scripts (bash, pyton, etc), without any problem.

Module is able to catch bytes up to 921600 baudrate, with and without flow control.

I can only assume that module is not really receiving 5 bytes when your printf sends out 5 bytes. Check your STM32 application (before), and use an oscilloscope (also) to be sure that STM32 is really sending 5 bytes.

There is an application note, with related firmware package running on

STM32F0DISCOVERY

. If you want, you can use that package as reference ( http://www.st.com/web/en/catalog/tools/PF260583 )

j