CC3220SF: NWP crashes sporadically

Hi,

The NWP logger has been shared many times before.

You just need to insert->Image/Video/file.

Shlomi

NWP_Logs.zip

Hi,

Here are the log files. I would like to give additional details of the problem that occurs. Http request are send correctly for some time, and than NWP does not forward the request to the MCU, which is in idle task. After that all the requests are answered wtih error 404 by NWP, and not by Http Server.

Hi,

The logs are not decodable. Have you fetched logs in the past?

Is the chip CC3220 or CC3200 since you use both?

Shlomi

Hello Shlomi, Im tagging in for my colleague

We have not fetched loggs in the past
We are currently using a CC3220SF Launch XL to test this, in which UART2_0 is connected through header pins 55 and 57 to external board. Am i correct in assuming that we need to switch our external connection to UART2_1 to enable NWP logging through UART2_0? It is necessary for us to have the connection to the external board to demonstrate what the problem is.
If so i am also assuming we need to configure UART2_0 using the uart2 driver to the settings given in the document (Baud:921600, 8N1)? Or is it enough to just add the lines:

// If your application already has UART0 configured, no need for this line
MAP_PRCMPeripheralClkEnable(PRCM_UARTA0, PRCM_RUN_MODE_CLK);
// Mux Pin 62 to mode 1 for outputting NWP logs
MAP_PinTypeUART(PIN_62, PIN_MODE_1)

To initialization as per the document

Hi Shlomi,

 I've attached the updated log files for your review. Could you please confirm if they are now decodable?

5621.NWP_Logs.zip

yes, these are decodable but looks normal. I assume it does not include the issue, right?

Hello Shlomi, Ilija tells me that the problem should appear in those logs. We sent requests untill we could no longer receive them on the CC3220SF MCU, but we keep getting 404 responses. We will record the logs again just in case, he will post them soon

Project is based on this. Looking in debug the MCU is still completely operational once the bug happens.
Is there anything else you can think of that would prevent us from receiving the http request on the MCU? As far as we can tell once this problem appears, the mq_recieve function never triggers and we keep getting 404 responses directly from NWP.

Hi Shlomi, here are new log files.7360.NWP_Logs.zip

thanks, will look into it on Sunday when I am back from weekend.

Hi,

I don't see any specific reason that the host should get stuck.

I can see that once in a while you get the 404 error.

If a file named "www/err_404.html" exists (which is true in your case), cc3220 sends it to the client as HTML 404 NOT FOUND page.

Maybe this is what you see.

But I could not see that the host stops responding.

Shlomi

Hello Shlomi,

The 404 response should not happen. The same requests are forewarded to the MCU normally before it happens, after it happens the first time the requests never again reach the MCU, and we keep getting the automatic 404 response from the NWP.
As mentioned before looking in the ROV of the MCU code, everything seems to function normally, sl_Task and HTTP server task are blocked in normal places, as if waiting for a request to arrive but it never does. It is as if the NWP is stuck sending the 404 response automatically to every request that arrives.
We dont know why it happens the first time, as the same requests function normally before that but after a seemingly random number of times this error will happen.
We dont know why after it happens for the first time we never again recieve the request on the MCU and the 404 responses are sent automatically
Do you have any advice on how to further look into this issue?

If it makes any difference we are currently using the 5.20 version of the SDK due to compatibility and certification transfer issues

Hi,

At least from the logs, it seems that the NETAPP_REQUEST is coming from the NWP and the corresponding NETAPP_RESPONSE is triggered back to NWP from the host with a pending flag as in other good cases. I assume that other commands (not HTTP) are also working from the host, right?

So we need to understand why you are not seeing any NETAPP_SEND after the pending flag is signaled. Where in your code does it trigger the NETAPP_SEND?

Shlomi

So, the request on the cc3220sf MCU can be received in only one place, through mq_receive inside the HTTP server task, this part was not modified from the example given a few responses ago. In earlier corespondences about other problems with Kobi, i have determined that the sl_Task is in charge of receiving the request from the NWP and unblocking the HTTP server task which reads the request from the queue.

We send the response using sl_NetappSend, in one of two ways. Either its called from the callback function of the http requests once it is parsed, or the request is saved in the http request callback, and sl_NetappSend is called in the UART callback after receiving an Uart response from the external board.

We are seeing neither the mq_receive or the sl_NetappSend triggered in debug after the bug happens. Untill the bug happens we see them triggered normally

sl_Task() is responsible to get the NETAPP_REQUEST and reply with NETAPP_RESPONSE with the pending flag. You can see it in _SlNetAppEventHandler() under SL_OPCODE_NETAPP_REQUEST case. It also calls the matching application handler via the _SlDrvDispatchNetAppRequestEvents(). This handler usually calls for the NETAPP_SEND. If you are using a message queue to pass from the handler to another task, you should check if you get to the handler and if you do, maybe the message queue is crashed/full/other.