AnsweredAssumed Answered

CubeExpansion Wifi v2.1.0 - concurrency problem

Question asked by Spock.ncc1701a on Jul 11, 2016
Hi all,
I am working with the following hardware to obtain a "proof of concept" before starting new hardware development:
- STM32L476 discovery
- IDW01M1 nucleo board
Connected the two boards, using L476 USART2 for communication with IDW01M1.
This is the Access Point.
- STM32F746 discovery
- IDW01M1 nucleo board
This is the "client".

Software: using STM32CubeExpansion for WiFi v2.1.0 libraries ; I am writing application code using FreeRTOS.

L476: started "mini AP mode" with IDW01M1 and activated "socket server" mode ; this is OK.
F746: it connects to the mini AP and successfully opens a socket.

Back to L476: when the client opens the socket, this triggers a call to "ind_socket_server_client_joined", which puts a state variable to "write mode". Main loop then executes a "wifi_socket_server_write" to "push" an UNSOLICITED message to the client.

These are the problems (message is "TEST1"):
1) client side: I receive "AT+S.\r\nTEST1". Client sends this back to server as an ack. Why am I receiving "AT+S." ??? It's the sequence of the server to put it on data mode...
2) server side: the answer from the client gets lost, because it arrives when the "server" is still in "data mode" and going to "command mode".
See "wifi_socket_server_write" in wifi_interface.c :

if(HAL_UART_Transmit(&UartWiFiHandle, (uint8_t *)pData, DataLength,1000)!= HAL_OK)
      return WiFi_HAL_UART_ERROR;
  //HAL_Delay(100);//Wait for tx before switching back to command mode

<<<<<<< HERE I receive the answer from the client !!! >>>>>>>

  /*Switch back to Command Mode*/
      WiFi_switch_to_command_mode();//switch by default
          //Wait till command_mode is active
          __NOP(); //nothing to do

If I follow the execution with debugger I see that the answer from the client is later discarded.
On the server: the problem seems that the server wants to return to command mode after sending data to client, and this introduces a concurrency issue.
On the client... receiving AT+S ?
Any help on this is highly appreciated : what am I doing wrong ?
The idea is to open a socket and then have a full duplex "transparent" connection ; about point 2 (concurrency) I could try with client asking and server answering, but I would loose full duplex...

best regards