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.

CC3235MODSF: What are the reasons for the explicit security alerts?

Part Number: CC3235MODSF

To whom it may concern,

For a certain time, I had an issue with the device locking itself. To figure it out, I designed a simple test case. So, the device starts and restarts after some time has passed (7-9 seconds). All the logs during startup are printed over UART. After ~2 hours of testing, the device locks itself without triggering any security alerts. According to the network processor user guide, this happens due to an explicit alert. I can't understand why this happens, because the device does literally nothing. What are the reasons for the explicit alerts? I need all of them, btw, to start working on a solution, and as of now, I still don't understand why the device locks itself at all. Here below you can find logs from the file system:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Read files list:<\n>
[ 1] dummy-root-ca-cert <9> 3656<9>0x020<\n>
[ 2] /www/css/style.css <9> 11848<9>0x020<\n>
[ 3] /www/images/tim_icon.png <9> 3656<9>0x020<\n>
[ 4] /www/index.html <9> 11848<9>0x020<\n>
[ 5] /sys/ipcfg.ini <9> 3656<9>0x040<\n>
[ 6] /www/js/jquery.min.js <9> 65096<9>0x020<\n>
[ 7] /sys/pmcfg.ini <9> 3656<9>0x040<\n>
[ 8] /sys/stacfg.ini <9> 3656<9>0x040<\n>
[ 9] /sys/pref.net <9> 7752<9>0x050<\n>
[ 10] /sys/ap.cfg <9> 3656<9>0x040<\n>
[ 11] /sys/dhcpsrv.cfg <9> 3656<9>0x040<\n>
[ 12] /sys/httpsrv.cfg <9> 3656<9>0x040<\n>
[ 13] /sys/mode.cfg <9> 3656<9>0x040<\n>
[ 14] /sys/devname.cfg <9> 3656<9>0x040<\n>
[ 15] /sys/phybg.cal <9> 11848<9>0x040<\n>
[ 16] /tmp/table.arp <9> 3656<9>0x040<\n>
[ 17] /sys/dhcp.bin <9> 3656<9>0x040<\n>
[ 18] /tmp/crashminidump.bin <9> 28232<9>0x020<\n>
[ 19] /sys/certstore.lst <9> 7752<9>0x2d0<\n>
[ 20] /sys/servicepack.ucf <9> 134728<9>0xad0<\n>
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


BR,

Alex

  • Hi,

    There is nothing much you can do from application layer as the device gets locked during the bootloader section when the device boots up.

    To pin point on the exact reason, you would need to fetch NWP logs.

    Do you have this capability?

    It is all described on the user guide in section 20: Debug.

    BTW, how do you reset the device exactly?

    Shlomi

  • Hi,

    Do you have this capability?

    I need to include some headers for the NWP logs and test it again. It will take some time.

    how do you reset the device exactly?

    By turning the power down and turning it on again.

    BR,

    Alex

  • Hi,

    Thanks. Regarding the power, if you ungracefully turning off and on, it may cause issues if the device was in the middle of writing into the serial flash or it got into some intermediate state (brownout).

    Are you powering off and on manually or by SW? if you do it by SW, you should call sl_Stop(timeout) followed by sl_Start(). The timeout is important to let the NWP shot down everything gracefully (also interaction with the serial flash).

    Regards,

    Shlomi

  • Hi,

    I do it manually. Soon, I will provide you the NWP logs.

    BR,

    Alex

  • OK, thanks.

    Please let me know when you have it.

    As I mentioned, manually resetting the device may end up with unexpected results if the serial flash was in the middle of writing/programming.

    But, let's wait for the logs.

    Maybe I can see something over there.

    Regards,

    Shlomi