Other Parts Discussed in Thread: CC3120,
In December, it was suggested on E2E that I use the 3.17 service pack from the CC3220 SDK because it solved an issue where the Wi-Fi Scan stopped working. When I upgraded our AWS MQTT implementation to the latest version, I added a send timeout using the socket option with SLNETSOCK_OPSOCK_SND_TIMEO. I experienced a lot of disconnects and hang-ups and switched back to service pack 3.16 and found it rejected the SLNETSOCK_OPSOCK_SND_TIMEO. Once I remove the SLNETSOCK_OPSOCK_SND_TIMEO socket option call, the problems disappeared. This leaves me wondering if the 3.17 service pack can safely be used with the CC3120 4.20 SDK.
My second question has to due with the CC3120 to MSP432 SPI clock. I have had some random socket and fatal Wi-Fi errors and was wondering at first if it was from the 3.17 SDK so I went back to 3.16. This seemed to reduce the failures, but they are so random its not clear. On one of our controllers that continued to have failures I tired a smaller resistor on the SPI clock which also seemed to reduce the failures. A direct connection does not work so we started with a 1K resistor. This resistor has worked for the last year, but with MQTT the probability of a fatal Wi-Fi error has increased possibly due to additional socket activity. My question is whether an SPI clock that is rounded from large resistor could have reduced the reliability of the SPI interface and led to occasional socket errors and fatal Wi-Fi errors. We run HTTP and MQTT on separate threads which normally works great with the exception that I couldn't let them connect at the same time and still have a task to get network logs for that problem.
Gary Klinefelter
