• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 41 subscribers
  • Views 413 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/CC3220SF: SL_DEVICE_EVENT_FATAL_DRIVER_ABORT Event NWP log

Jan D
Guru 73255 points
Part Number: CC3220SF

Tool/software: Code Composer Studio

Hi Team,

I found SL_DEVICE_EVENT_FATAL_DRIVER_ABORT issue with my code. I would like to ask for analysing captured NWP log, whether there is any clue.

I have relatively complex code. One part of this code is a http 1.1 server running at application processor (for max. three simultaneously connected clients at TCP port 81). I found a issue with fatal driver abort in case I receive large POST request but I don't read all incoming data from sokcet (that mean some RX data will be still at receive buffers inside NWP). It does not look like a buffer overflow or stack issue inside my code. After driver abort is my code still running and ROV does not signalise any issue.

In NWP log attached below you find data which begins at device reset and ends 2-3 sec after driver abort is reported by asynchronous handler.

Important sl_ API call before driver abort is returned:

  • TCP socket with www browser is already opened. I use http 1.1 server, from this reason can be TCP connection still opened between POST/GET requests.
  • WWW browser sends http POST request with size approximately 14kB (Content-Length: 13632, as shown at Wireshark log below)
  • By calling non-blocking sl_Recv() API I read beginning data from POST request. It is about 1-1.5kB. Enough to be found "Content-Length" and determined value of rest of content.
  • From content "Content-Length" I determine that I haven't enough space inside my internal buffers (I have 10k buffers).
  • From this reason I don't read rest of incoming data (rest of content).
  • I send back http response 400 back by sl_Send() API (to notify browser what request was not proceeded).
  • After that there is 50ms sleep (some other task will do some other stuff, maybe some sl_ API call could be there).
  • Abort asynchronous handler is triggered.
  • All consequent sl_ API calls (sl_Recv(), sl_Close()) does returns SL_API_ABORTED (-2005L). This is expected because abort handler was triggered before.

Device information:

  • CC3220SF LaunchPad
  • SDK version: 3.30.01.02
  • ServicePack: 3.13.0.3

NWP log:

nwp_log.zip

Wireshark (only problematic "log" POST which caused fault):

wireshark.zip

 

Thank you for advice.

Regards,

Jan

  • 0
    TI__Mastermind 38980 points

    Hi Jan,

    I'll take a look and see if I can give you some insight tomorrow.

    Thanks,

    Sarah

  • 0 in reply to Sarah P
    TI__Mastermind 38980 points

    Hi Jan,

    Apologies for the late response, but I only see the boot-up sequence in this log. The file is about 6 KB, where I would expect a full log to be roughly 30-100 KB. Are you able to retake it?

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Guru 39650 points

    Hi Sarah,

    Attached is a new log. It seems that my feature which allow to switch UART to NWP log without recompiling had some bug and log was captured only at startup. I will look on it later, for this moment this is not important.

    I was able capture additional log. It have 45k and I hope that should be fine. Code was captured with slightly different configuration, because my original code I don't have here now. But same error should be there.

    What should be there:

    • device boot
    • opened TCP server, incoming long POST as described above
    • abort event SL_DEVICE_EVENT_FATAL_DRIVER_ABORT
    • restart by PRCM API (restart API is triggered by my code inside fatal handler)
    • part of 2nd boot after restart

    20200121192533.zip

    Regards,

    Jan

  • 0 in reply to Hnz
    TI__Mastermind 38980 points

    Hi Jan,

    I'm sorry, it looks like your new log got corrupted. It's the right size, but if I open it as a text file, there is a lot of "<0>" where I would expect symbols. Can you try one more time?

    Best regards,

    Sarah

  • 0 in reply to Sarah P
    Guru 73255 points

    Hi Sarah,

    It seems that terminal software from some unknown reasons saved character 0x00 as <0>. That mean is should be enough in hex editor replace text <0> to single hex character 0x00. I have done this simple change at previous log. I captured new log with different hardware (by my hardware with CC3220SFMOD instead CC3220SF Launchpad) and different terminal software as well.

    Previous log with exchanged <0> to 0x00:

    20200121192533_removed_wrong_characters.zip

    New log:

    putty.zip

    Jan