• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 40 subscribers
  • Views 575 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3220SF: Proper way to get NWP status from SimpleLink SDK

Vadym Mishchuk
Intellectual 305 points
Part Number: CC3220SF

Hi,

I am working on project which contains a lot of threads using SimpleLink API in different ways (sockets, Wifi control and SimpleLink FS). Currently we are facing issue with unstable network functionality within our firmware. It is hard to reproduce and we are not able identify what is the sequence of events that triggers the issue. n our software we are processing all known SimpleLink notifications(events), but it might be that we are still missing something. So current intent is to do a bit defensive programming and add extra thread that will periodically check the status of NWP and report failures or some changes in state that we might not expect.

The question is what is the proper way to implement control of NWP status: if it is locked, entered error state and needs to be reset? Is there any way how to check status of that periodically?

  • 0
    TI__Mastermind 40965 points

    Hi,

    There is no API or method to fetch the full status of the NWP - you will largely need to perform checks on the return values of the SimpleLink APIs that you call and ensure that you do not encounter any errors. If errors are encountered, logging those and then performing the appropriate corrective action (usually performing a sl_stop/sl_start to reset the NWP and then re-init your socket connections) is advised.

    If you are unable to debug the issues you are seeing purely through checking error values and monitoring the async event handlers, then you can capture the NWP logs and provide that to me alongside a description of how the issue manifests on your system. With that, I can give some debug pointers based on what the NWP state is during your issue.

    See section 20.1 of the NWP user's guide for more information: http://www.ti.com/lit/swru455

    Regards,

    Michael

  • 0 in reply to Michael Reymond
    Intellectual 305 points

    Thanks Michael

    That might be helpful for us, but I am not sure  which pin is needed. Issue is reproducible on our custom PCBAs with CC3220MODASF and a lot of other parts. NWP user's guide tells that I shall output logs to pin62, is that GPIO7(pin number 52 on CC3220MODASF pinout) ? NWP user's guide also mentions that UART0 shall be configured. Could you give us a bit insight on how this NWP log output works? I am asking because our application uses both GPIO7 and  UART0 and I thinking how we can get logs and preserve functionality with minimal soldering and minimal changes in code. 

  • 0 in reply to Vadym Mishchuk
    TI__Mastermind 40965 points

    Hi,

    Yes, you are correct, GPIO7 is the pin that will be used to mux out the NWP logs. This will correspond to pin52 of the module - the instructions in the NWP user's guide reference the CC3220 chip.

    The NWP log output is from an independent UART peripheral on the CC3220 NWP ARM core. The only inter-dependency is on the power and clocking to the UART - in order for the NWP debug UART to be functional, the UART0 of the main MCU needs to be powered/clocked.

    If you are already using GPIO7, then there are alternate locations that you can mux out the debug NWP signal. Specifically, these are all of the possible options:

    • MAP_PinTypeUART(PIN_53, PIN_MODE_5);//GPIO30
    • MAP_PinTypeUART(PIN_18, PIN_MODE_3);//GPIO28
    • MAP_PinTypeUART(PIN_60, PIN_MODE_3);//GPIO5
    • MAP_PinTypeUART(PIN_62, PIN_MODE_1);//GPIO7

    Do any of those GPIOs work for your system?

    Regards,
    Michael

  • 0 in reply to Michael Reymond
    Intellectual 305 points

    Hi, Michael

    Thanks for info. Redirecting logs to GPIO5 shall do the trick. 

  • 0 in reply to Vadym Mishchuk
    TI__Mastermind 40965 points

    Hi,

    If GPIO5 works, then please replace the following line in section 20.1:

    MAP_PinTypeUART(PIN_62, PIN_MODE_1);

    With the function:

    MAP_PinTypeUART(PIN_60, PIN_MODE_3);//GPIO5

    From there you should be able to get UART output out of that pin. It will be encoded raw binary, but if you provide that to me I will take a look and might have some insight into your issues.

    Regards,

    Michael