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

program crash

Narendra Kulkarni29
Intellectual 590 points

Board DK-TM4C129X.

Controller: TM4C129NCZAD

OS - TI-RTOS 2.12

CCS 6.1 (using Free License as we awaiting the license) and TI ARM  Compiler 5.24

We are having an application with multiple Tasks (totally 5). All are running with same priority. Two tasks are used to read from peripherals and 1 task is used to send data over the same peripherals. Other tasks are the display task to display on LCD. The core task (core functionality) is 5th task. MailBox is used to sync data between tasks. 

We are facing a peculiar problem where in the application is crashing in the  display task. We have ensured stack size is OK.   While analyzing the crash, we see that commenting random part of code with substantial lines of code,  either in display task or the core task The application does not crash.  This seems to some sort of code size issue,  Is there any limit on the code size?

  • 0
    TI__Mastermind 45025 points

    Hi,

    Narendra Kulkarni29 said:
    We are facing a peculiar problem where in the application is crashing in the  display task.

    What kind of output are you seeing when this happens?  Is there a register dump?

    If so, you can use that info to help trace back to the cause of the crash.

    Please see this BIOS FAQ for details.

    Steve

  • 0 in reply to Steven Connell
    Intellectual 590 points
    Steve,

    Thanks for the reply.

    I am getting a BUS FAULT Error, which indicates illegal address read/write. I used the BIOS FAQ and got callback trace. The trace indicates, Its crashing in a graphics library function APIs called in the display task. The weird thing about of this crash is if I comment out a part of the code in the core task, you wont see the crash. The other weird thing I observed is the other 4 tasks are in ready state and only display task is running and gets preempted, when the crash happens.

    TIA

    Narendra
  • 0 in reply to Narendra Kulkarni29
    TI__Mastermind 45025 points

    Narendra,

    I wouldn't recommend commenting out code in order to solve this.  The crash may be being caused by some code stomping on (overwriting) memory that it shouldn't.  When you comment out code, you may be changing the layout of the program in memory such that the bad code is still overwriting the memory location that it should not be, but you won't see it because the data location it was previously corrupting is no longer in that location.

    In the worst case, there is nothing at that location in memory, and so you won't even know that the code is behaving badly until sometime later when some valid data is stored there and then corrupted by the bad code. (e.g. it keeps overwriting an address that it shouldn't, but since nothing critical is stored there, the corruption goes undetected.  So, only when something critical is stored in that location and then subsequently overwritten, will the app crash).

    This is probably what's happening in the following case that you mentioned:

    Narendra Kulkarni29 said:
    The weird thing about of this crash is if I comment out a part of the code in the core task, you wont see the crash.

    What I would recommend doing in this case is to use the debugger to single step through the application until you can track down the bad code.

    For example, I would start in your display task.  Put a break point at the graphics API call that you found from following the steps of the BIOS FAQ.

    Once you reach that break point, do a "step over" with the debugger.  Does the crash happen?  If not, run the app until the break point hits again and repeat (be sure to keep a count of how many times you have hit the break point).  Repeat until the crash happens.

    For example sake, say the crash happens on the nth time.  Now, you can restart the app and skip over each of the n - 1 calls.  Now you're at the nth call to the culprit function.

    Step into that function, and single step until you see the crash occur.  Or even use "step over" to see if the crash happens in one of the function calls made within the graphics lib API.

    Be sure to keep track of how far you've made it with your single stepping, so that if the crash happens again, you can use a break point to pick it back up where you left off.

    Steve