CC3220MODA: Waking up from hibernation (power cycle) ends up in locked (not booting) state

Why do you suspect a power issue?

Did you see any indication of low power on your board? Can this be reproduced on the launchpad?

To get more info on the issue, you can get the NWP logs (see ch. 20.1 in the cc322p NWP Programmer's Guide).

I am suspicious about power issue as it looks really similar as the symptoms described in https://e2e.ti.com/support/wireless-connectivity/wifi/f/wi-fi-forum/795818/cc3220mod-mcu-reset-after-a-local-ota-update

And it is really hard to reproduce on my desk it is like 1 per 100 reboots (or OTA updates). As I don't have exact reproduction steps yet, it is hard to say if it works on launchpad. But usually on devices in the field, which are running for longer time and have different temp conditions, we have about 10-20% chance to stay stuck after power cycle (so, thats why I was expecting some issue during calibration)

Is there any tool available for reading the NWP logs? It may help me to understood, if the logging is correct, before trying huge number of retries and investing lot of work for reproduction. 

We are not familiar with such issues. Please go through the SIMPLELINK-WIFI-DESIGN-REVIEWS to verify your implementation.

THE NWP logs can only be parsed internally by TI  (currently). You can send a log for us to verify the content.

Are you using watchdog timer for the OTA? Does it work in this failed cases? 

I will ask HW team to check the design review. 

We are using the watchdog, but it doesnt help. It seems we stay locked in some weird state. 

I have two NWP logs - one is test log NWP_test.bin - just to see if the data are correct
And second log from actual freeze during power cycle NWP_1619095695.bin

I Will check the logs, but you should make sure you go through the hw review process.

Any news about the logs? 

There is something strange in the logs - seems like you are calling SOCKET_SELECT? I do see many triggers from the select.

Can you close the socket and then call sl_Stop before doing the MCU reset?

Have you gone through the HW review?

Br,

Kobi

The HW review is ongoing (I asked HW team to help me there). We are having custom implementation of http server, so calling socket select should be correct. I believe, we are closing the socket and calling sl_Stop before the MCU reset .. or do you see something different in the logs? 

I saw some strange behavior of the select (many events are being issues in a very short time just before the mcu reset). I couldn't see that the socket got closed.

Please make sure the socket is closed and then the NWP (sl_Stop) before triggering the reset.

I haven't seen something like this before and it might relates to hw issue.

Hi Igor,

I reviewed the design files and just emailed you my feedback.

I suspect that the issue is coming from the LDO which is only capable of outputting up to 500mA. If you refer to the CC3220MODA datasheet, you'll note that the peak calibration when operating at 3.3V can be up to 450mA. 

It is good EE practice to at least double the LDO output depending on what else you need to power on your board. It is good EE practice to double the LDO output or more depending on what else you need to power on your board.

BR,

Seong