SPWF04Sx - AT+S.FSP

[yoann LBY]

Posted on December 07, 2017 at 16:02

hi,

stm32F401RB + en.x-cube-wifi1_firmware_v3.0.2

SPFW04Sx + UART + FW1.1.0

in my code i use AT+S.FSP and i want to catch the USART_Receive_AT_Resp in the buffer.

My problem is that response doesn't give +WIND and i don't know how to process the response!

in wifi_module_uart_04.c i check Process_DMA_Buffer_Messages() message type is case OK:

/*Now Check to which AT Cmd response this OK belongs to so that correct parsing can be done*/

go to else

//This is a standalone OK

                /*Cases possible                - TLSCERT,TLSCERT2, TLSDOMAIN, SETTIME                - S.SOCKW, SOCKR, S.SOCKC, S.SOCKD (open a server socket)                - File Operations                - S.GPIOC and S.GPIOW                */

I don't know and see what code i must add.

The goal is to put response in a buffer and manage it in the main.

thks

yoann

[yoann LBY]

Posted on December 07, 2017 at 16:30

To continu:

when i run in the code

//main.c

status = wifi_file_print_content((uint8_t *) RootCertFileName);

Read_DMA_Buffer is call  (void HAL_UART_RxCpltCallback(UART_HandleTypeDef *UartHandle)

in the dma_buffer, i don't receive the beginning of the file. (lose the first 796 caractere for a total of 1322)

[yoann LBY]

Posted on December 08, 2017 at 13:58

'To continu:

when i run in the code

//main.c

status = wifi_file_print_content((uint8_t *) RootCertFileName);

Read_DMA_Buffer is call  (void HAL_UART_RxCpltCallback(UART_HandleTypeDef *UartHandle)

in the dma_buffer, i don't receive the beginning of the file. (lose the first 796 caractere for a total of 1322)'

Buffer is circular so the complete response of the cmde AT+S.FSP is in the buffer. But whaqt is the good process to catch response!

i am trying to modify the Process_DMA_Buffer

/* Response Received..AT-S.*/ with test WiFi_Control_Variables.enable_receive_file_response

i will inform on my progress.

I hope i am in the good way/solution.

yoann

[Gerardo GALLUCCI]

Posted on December 11, 2017 at 10:49

You can think about the IDLE interrupt over UART: when it fires, all data (between AT+S.command and AT-S.OK/ERROR) were printed, and final OK/ERROR was given (+ 'timeout').

Worst case: a '+WIND:something' has come after the OK/ERROR. In this case, IDLE interrupt follows the WIND, and not the OK/ERROR. But it's a simple case to manage.