Testing continues. I have expanded the loop to include the first query the host sends to the sn8200. This is WIFI_GET_STATUS_REQ with the third byte (Interface) set to 1 => AP. Our application does not use the AP so the first thing done is to see if it is on and if so, turn it off with the persistence flag set to make the change permanent. The code will take this path one on the first startup but the test remains forever. The loop consists of:
1) 100 ms reset (and count resets)
2) 3 s delay (and count GEN_PWR_UP_IND_RSP messages)
3) issue WIFI_GET_STATUS_REQ (for AP)
4) 3 s delay, count receipt of WIFI_GET_STATUS_RSP
5) repeat loop
(Before starting the test I power cycle the sn8200 to bring it to a known state.) I run this for about 30s and examine results. The code counts 5 resets, four outbound status requests, zero power reason messages and zero replies to status request. I examined the analyzer output and can find the four outbound messages but not a single message sent by the sn8200.
Repeating the test I get six resets, one status response and one power up response. The status response, however, is not for the query that the host issued,. It is a response to WIFI_GET_STATUS_REQ for STA and includes the null terminated string for the SSID to which it has attached. Examining the buffer fromthe protocol analyzer I also see several WIFI_NETWORK_STATUS_IND messages which I understand the sn8200 sends unsolicited. There are no messages found in the buffer that are not interpreted by the code. In other words, I can find no evidence that the host is missing any messages that the sn8200 sends.
Due to the unexpected messages received, I decided to explore the first message sent unsolicited to the host. I repeated the loop described above except that I extended the first delay to over 30 seconds. Then I repeated the test, power cycling the sn8200, releasing the reset and timing arrival of the first message. I found the following results.:
885 ms - GEN_PWR_UP_IND_RSP
30 s - no message
776 ms - GEN_PWR_UP_IND_RSP
30 s - no message.
Each time I examined the protocol analyzer buffer for messages and found exactly what the code found.
I repeated this test but without power cycling the sn8200 and in three tries got no unsolicited messages.
I continue to be puzzled buy the inconsistent behavior of this device.
A helpful person on the STM forum suggested that the sn8200 requires a transition on the NSS pin in order to communicate effectively. I implemented that and communication seems much improved. Behavior is still curious, for example if the WIFI_DISCONNECT_REQ is issued, it seems to take many tries to reestablish a connection.