• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 308 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.

TMS570LS3137: Determining The Location Of Null Function Pointer / No Stack Info

Kier
Mastermind 9470 points
Part Number: TMS570LS3137


Hello,

Our project ran for about 700ms then the PC appeared to spontaneously change to 0x00000000 and so the program effectively restarted over and over. We set a BP at 0x0 and after ~700ms we hit it. However, there is no stack frame displayed in the debugger to show us the context of the PC = 0x00000000.

We eliminated reset as cause and my colleague eventually found the cause was a null function pointer but only after many hours of work.

1) Why isn't there any stack info in the case of a null function pointer changing PC to 0x0 please?

2) Is there an alternative debug technique to determine what code changes the PC to 0x0 please? We don't have any on/off chip trace facilities unfortunately.

Thank you very much.

  • 0
    TI__Guru 73291 points

    Hi Kier,

    It is difficult to find out the root cause for the issue with this information.

    Is it possible to provide some simplest code for debugging issue at my end.

    And also if you are using HDK board, we find one interesting observation for HDK board for watchdog reset please refer below FAQ for that:

    (+) [FAQ] TMS570LC4357: How to use Digital Watchdog - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    Also try to verify the exact value of SYS Exception register before clearing it.

    As you can see in the code, we will do clear the exception register once we verify the reset cause in the startup file. so please do verify before 152 line as shown above.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Mastermind 9470 points

    Many thanks Jagadish.

    This is custom hardware rather than any development board.

    We have eliminated reset as the cause and proved it is a null function pointer. This was difficult to track down but now we have fixed it.

    To avoid the same problem in future we would like to know how to find the location of any null function pointer dereferencing. At the moment, the stack frame just shows 0x00000000 with no other info. Our aim is to improve that somehow.

    We shall try to demonstrate the issue with a code snippet. since only you have the hardware can you demonstrate the problem by inserting the nulll pointer problem and providing the code snippet and screenshot of the (empty) stack frame?

  • 0 in reply to Kier
    TI__Guru 73291 points

    Hi Kier,

    On my knowledge we can identify null function pointers in two ways.

    1. One way is to add the function pointer in expression window and need to verify its assigned value.

    As you can see, if we didn't assign any value then the corresponding function have NULL value.

    2. Set a breakpoint at reset entry and run the code, if our application hits this breakpoint then verify the R14 and LR register values.

    These two register values will give address closer with the last execution. Actually, these registers will hold the next address to be executed but unfortunately, we jump from that execution but still will hold those values.

    So now open the disassembly window and enter this value there and see the function near to that.

    --
    Thanks & Regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Mastermind 9470 points

    Thanks for the tips Jagadish!

    1) We don't know which function pointer might be null so unless we watch all function pointers in the program, I don't think this is a practical proposition.

    2) This looks like the best method. We'll look for this next time it happens.

    Thanks again.