3 Replies Latest reply on Sep 11, 2015 7:37 AM by MichaelF_56

    SN8200 and GEN_PWR_UP_IND_RSP message

      I continue to have difficulty managing the  sn8200 via SPI. There are many instances where the host application (running on an STM32F429I-Discovery board) does not receive the expected response from messages sent to the sn8200. This morning I put a Beagle protocol analyzer on the SPI bus and ran some tests. The first interaction with the host is to assert reset, power up the sn8200, hold reset for 100ms and release reset. At that point the application waits for the GEN_PWR_UP_IND_RSP message which is sent unsolicited from the sn8200.

      Present H/W does not control power so the effect is to simply assert reset for 100ms. I have programmed this in a loop where it asserts reset and then waits for 3s for the power up message. On the first test, it received the power up reply once following eight reset operations. I captured the SPI traffic using the analyzer and can only find the reset message that the host application saw.


      It appears that the sn8200 only occasionally sends this message following reset. Is that the behavior I should expect?



        • 1. Re: SN8200 and GEN_PWR_UP_IND_RSP message

          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.

          • 2. Re: SN8200 and GEN_PWR_UP_IND_RSP message

            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.