Posted on July 11, 2016 at 11:48Hi 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)
{
Error_Handler(EH_WIFI_UART_ERROR_TX);
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*/
if(!IO_status_flag.command_mode)
{
WiFi_switch_to_command_mode();//switch by default
while(!IO_status_flag.command_mode)
{
//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...
Thanks,
best regards
