• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 414 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.

RawEthSockPcbFind causing debug error

Sergio Kamakura
Expert 2495 points
Other Parts Discussed in Thread: TM4C1294NCPDT

Hi

I am developing a firmware for TM4C1294XL board using UDP protocol under TI-RTOS. With the firmware running from hours without any problem, suddenly  I have a debug error occurring systematically in the same module ( RawEthSockPcbFind ), as can be seen in following debug dump:

ti.sysbios.family.arm.m3.Hwi: line 1036: E_hardFault: FORCED
ti.sysbios.family.arm.m3.Hwi: line 1113: E_busFault: PRECISERR: Immediate Bus Fault, exact addr known, address: 482dfc97
Exception occurred in background thread at PC = 0x0001b844.
Core 0: Exception occurred in ThreadType_Task.
Task name: {unknown-instance-name}, handle: 0x20019bb8.
Task stack base: 0x20005b80.
Task stack size: 0x600.
R0 = 0x000086dd  R8  = 0x00000000
R1 = 0x2000f384  R9  = 0x00000000
R2 = 0x482dfc67  R10 = 0x00000000
R3 = 0x20019fd8  R11 = 0x20019860
R4 = 0x20019754  R12 = 0x00000000
R5 = 0x2000cdf4  SP(R13) = 0x20006088
R6 = 0x200195ac  LR(R14) = 0x00015f9f
R7 = 0x00000002  PC(R15) = 0x0001b844
PSR = 0x21000000
ICSR = 0x00423803
MMFSR = 0x00
BFSR = 0x82
UFSR = 0x0000
HFSR = 0x40000000
DFSR = 0x00000000
MMAR = 0x482dfc97
BFAR = 0x482dfc97
AFSR = 0x00000000
Terminating execution...

Attached follows the map file.

0842.map.doc

Analyzing the map file ( renamed to map.doc  ), I found that the address 0x0001b844 it is inside of RawEthSockPcbFind module.

As this module it is from the TI-RTOS library (NDK), I wonder that this issue could be a lack of stack or something related as lack of memory.

Someone could help me in this matter?

Sergio

  • 0
    TI__Genius 10825 points

    Sergio,

    Are you using raw sockets? Or is it UDP? Which IP protocol are you using?

    For debugging execution core dump in CCS,  please follow the steps in this wiki. It will provide you will call stack trace. Also, in CCS debugger view open Tools > RTOS Object View. This tool allow you to look into various RTOS objects when target is at halt. The modules of importance for your debugging would be Task > Detailed (check stack peak), Hwi > Exception (provides exception info) and BIOS > Scan for Errors.

    Vikram

  • 0 in reply to Vikram Adiga
    Expert 2495 points

    Hi Vikram Adiga

    I am using UDP ( User Datagram Protocol ).

    The board it is not connected to CCS. It is stand-alone, because it is connected to a mainboard that has several inputs and outputs that TM4C1294NCPDT is controlling.

    The dump I listed was printed in the console ( serial ), as the actual firmware is in debug mode.

    I don't know why the problem is occurring in the RawEthSockPcbFind module. Anyway, I wonder that it is this module, due the address (0x0001b844) listed in the dump and crossed with the map file:

    0001b834    00000024               : rawethsock_pcb.oem4f (.text:RawEthSockPcbFind)

    I realized that this issue occurs when there is a heavy traffic in the intranet ( for example, when someone in my net segment is downloading something ). This is why I wondered that it is a memory problem ( buffers ).

    Is it possible to increase de information on the debug dump, when in stand-alone mode? I mean, without CCS connected to the board?

    Thanks,

    Sergio

     

     

  • 0 in reply to Sergio Kamakura
    TI__Genius 10825 points
    Sergio,

    I asked about raw sockets / UDP because the function "RawEthSockPcbFind" is executed only when raw sockets APIs are called. In case of UDP, it shouldn't be called.

    I am not sure if it is a memory problem in NDK libraries as they have sufficient stacks (at least as far as I know). NDK libraries can overflow only if there are callback hook functions registered to it and that callback function requires a stack bigger than that is allocated for NDK libraries. The NDK library stack size can be modified.

    Also, I wouldn't rely too much on the stack dump value to deduce that the exception is because of NDK library. There may be a stack overflow in the other parts of the code which resulted in the PC to jump incorrectly to a wrong memory location (in this case RawEthSockPcbFind) and start executing the code from there.

    Unfortunately, without connecting to CCS there is not much we can debug.

    Vikram