Bug in rsi_ftp_file_write_content() causing stack corruption and deadlock

[adam-durridge]

Sending data to an FTP server using multiple calls to rsi_ftp_file_write_content() can cause a serious bug to occur.

It can result in stack corruption (how I found it) and also gets the driver task in an incorrect state causing other Wi-Fi issues like lock ups until timeout.

It is due to how this SAPI call does not generate a response (RX Event) until the last chunk is sent. This

wiseconnect-wifi-bt-sdk/sapi/network/protocols/rsi_ftp.c

Lines 506 to 510 in c95f054

	#ifndef RSI_UART_INTERFACE
	if (!end_of_file) {
	rsi_driver_cb->wlan_cb->expected_response = RSI_WLAN_RSP_ASYNCHRONOUS;
	}
	#endif

sets that expected response.

The problem is that on the last chunk, even though this block does not execute due to end_of_file being set, rsi_driver_cb->wlan_cb->expected_response is still equal to RSI_WLAN_RSP_ASYNCHRONOUS from the previous call.

This causes a wait for semaphore instruction to be skipped,

wiseconnect-wifi-bt-sdk/sapi/network/protocols/rsi_ftp.c

Lines 524 to 528 in c95f054

	if (rsi_driver_cb->wlan_cb->expected_response != RSI_WLAN_RSP_ASYNCHRONOUS) {
	#ifndef RSI_NWK_SEM_BITMAP
	rsi_driver_cb_non_rom->nwk_wait_bitmap |= BIT(0);
	#endif
	}

which causes the wait/post flow of the driver to get out of whack and can produce some nasty effects. In my case a subsequent SAPI call was returning early instead of waiting and when the RX event it should have been waiting on was processed, it filled a buffer that had gone out of scope.

I fixed this one by adding an else clause:
else { rsi_driver_cb->wlan_cb->expected_response = RSI_WLAN_RSP_FTP; }
I'm not positive this is the appropriate response to use, but it seems to work.