Other Parts Discussed in Thread: CC3120, CC3120BOOST, CC31XXEMUBOOST
We're in the late stages of product development; things are working well connecting to AP and transferring files to a server.
However in extended tests, I find that the API is eventually hanging for simple operations like getting socket options. Using an RTOS, the rest of the system remains fully operational.
The firmware details are:
The chip number is : 0x31000000
The FW version is : 2.0.0.0
The NwP version is : 3.14.0.0
Phy version is : 2.2.0.7
Communication is over SPI at 1MHz
An example of where the API call is not returning
/// \brief get connection status
/// \return true for connected, false for error or disconnected
bool cc3120_socket::isConnected() const {
SWO_in_out z(__FUNCTION__);
int err = 0;
SlSocklen_t errSize = sizeof(err);
const int16_t ret = sl_GetSockOpt(currentSockID, SL_SOL_SOCKET, SL_SO_KEEPALIVE, (void *) &err, &errSize);
if (ret == 0) {
return true;
} else {
return false;
}
}
The SWO class is sending debug out SWO to show entry and exit from the function (using the destructor to ensure 'out' is messaged regardless of the code flow), which is how I know that sl_GetSockOpt has not returned.
It isn't always that API function; it seems to be true of several API calls on different runs. The failure can happen after 6 minutes (rare) an hour or six hours.
Is there some API debug that can be enabled to help track the issue down?
We've suffered before from an API mismatch to the module firmware before, so I've mentioned that above and I think it should be right now (at least we're not getting receive buffer overflows any more - with guard sections in place to check now)
There's a regular maximum stack usage for each thread that has lots of headroom, so no stack crash.
The SPI track distance from ARM processor to the CC3120MOD is short and the hardware has been through EMC testing, so I don't think there's an issue with corruption there.
Any suggests on how to determine what has upset the API?
