This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3120: WIFI FAILURE ON LONG RUN - ON GRID DEVICE

Part Number: CC3120

Tool/software:

We are currently facing an issue with the WiFi functionality in our reclosure product.

Since this observation comes from a customer site, we do not have complete data for analysis. However, based on general behavior and our logs, we are encountering a fatal error. As previously mentioned by ti, if we get a fatal error from the CC3120 chip, the application is expected to restart the WiFi chip. We have implemented this logic, and it is restarting, but at certain points, the WiFi is not working. We are unable to connect to WiFi, and in some cases, some cases the WiFi SSID is not visible outside. (Our devices are installed near a 15KV power line, on-grid devices).

Could you please help us understand the possible reasons for this wifi failure? Additionally, let us know the best time to discuss this matter.

  • Inquiry on Fatal Error and Chip Recovery

    Hello Team,

    Once the fatal error occurs, we understand the necessity to recover the chip. This condition is comprehensible based on the cyber security test results.

    However, over the long term, why does this error persist? We are almost certain that no cyber security activity, such as packet fuzzing or storming, has occurred on these devices.

    Outside of cyber attacks, what could trigger these fatal errors within the chip? I would like to focus on understanding that aspect.

  • Hi,

    You are using WiFi SoC next to high voltage devices. Do you have quantified EM field around device? Are there near some high voltage switches which can cause arcing?

    Do you use QFN CC3120 or CC3120MOD? If CC3120 QFN is used how is done shielding?

    Jan

  • Hi,

    if it is SL_DEVICE_EVENT_FATAL_DEVICE_ABORT, then most likely the NWP crashed and would be good to know the extra parameters (code and value on the event). Other events that are internal to the host like NO_CMD_ACK, SYNC_LOSS, CMD_TIMEOUT indicates sync loss with the device (e.g. SPI interface error) and reboot should recover.

    If you are not able to recover due to an assert, it may indicate some kind of file system corruption but hard to say without proofs.

    NWP log is really a must here.

    Regards,

    Shlomi