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

Help required on analyzing BIOS internal Buffers.

Ananth Nagaraj
Intellectual 765 points

Hi ,


On C6670 device my customer has around 15 task running and one of the low priority task stays in ready state even though the it has yielded to the semaphore. There could be as high as 8 preemption of this task for higher priority task to get completed. This happens randomly after few 10's of  iteration of working properly.

They dont use CCS is there away to find out what is going wrong in the system, could there be anything wrong internal to the BIOS  . Can we dump internal buffers of BIOS to find out and see how the tasks preemption's has happened.

We have used the BIOS API to do the stack analysis of the tasks and we feel there is no stack overflow issue seen.

One more strange behavior is if the priority of this task which is under problem is increased by one level , there is no issue seen wrt to the system working.


Regards,
Ananth

  • 0
    TI__Expert 8175 points

    Hi Ananth,

    Ananth Nagaraj said:

    On C6670 device my customer has around 15 task running and one of the low priority task stays in ready state even though the it has yielded to the semaphore. There could be as high as 8 preemption of this task for higher priority task to get completed. This happens randomly after few 10's of  iteration of working properly.

    I'm not sure I understand what your problem is. Is it that one of the low priority tasks never runs? Is it pending on a semaphore that's never posted? Or is the semaphore posted and task is ready to run but never runs? Also how are you determining that the task is in the ready-state?

    If the low priority task never runs that might not be a problem with BIOS but could simply be how the task priorities are chosen especially when you have a lot, like 15 tasks in this case. Preemption is expected to happen when other higher priority tasks are ready to run, so it may not be a bad thing. Also what version of BIOS are they using? Also since CCS isn't being used I'm curious, is TI compiler used or another toolchain?

    Thanks,

    Moses

  • 0 in reply to Moses Isang
    TI__Intellectual 765 points

    Hi Moses,


    Sorry for getting back on this really late .


    Task is ready but never runs , it is like the semaphore is posted--> task runs --> task get preempted but never comes back to execution from here..

    All this tasks are scheduled to complete in 1ms and  what we observe is there is a 200 microsecond idle time after all the 15 tasks run into completion before the next cycle starts.


    They use TI compiler , build the project using make files and run the code. They dont have JTAG connected to there board . Only way of communicating is through UART or through Logs over Ethernet.


    One thing I wanted to know is does BIOS execute a SWE/SWENR type of exception in case anything goes wrong within the BIOS. Or what all types of exceptions BIOS trigger in case of failures or any problem.

    Are there any diagnostic messages of BIOS , that could be accessed by user space or application.


    Regards,
    Ananth

  • 0 in reply to Ananth Nagaraj
    TI__Expert 8175 points

    Ananth,

    I think we need to understand why the task never runs. Does this happen every time? If the other tasks have higher priority and never pend or sleep then this behavior is expected. What code are the other tasks executing? Are your task stacks healthy? Can I see the code where the tasks are being created?

    Thanks,

    Moses

  • 0 in reply to Moses Isang
    TI__Intellectual 765 points

    Moses,

    Yes that is what I am trying to figure out why this particluar task does not run. No this does not happen every time  , it happens randomly after 40 or 100 iterations of excution , once this happens they run out of descriptors for next iteration and will stop their execution .

    Few of the task are getting posted by the HWI like VCP, TCP3d and FFTC.

    Tasks are healthy. We checked it.  I asked them for the code , which they are reluctant to share.

    Is there a way I can check the execution flow of system without the help of CCS. I mean can the BIOS scheduler flow can that be exposed ?

    Regards,

    Ananth

  • 0 in reply to Ananth Nagaraj
    TI__Expert 8175 points

    Ananth,

      You can turn on logs to see what's going on.

    • Enable BIOS logs by setting BIOS.logsEnabled = true in your cfg file
    • To enable logging for the Task module, add these lines to your cfg file,
    *.cfg code to enable task logging:
var Diags = xdc.useModule('xdc.runtime.Diags');
var Defaults = xdc.useModule('xdc.runtime.Defaults');
var LoggerBuf = xdc.useModule('xdc.runtime.LoggerBuf');
LoggerBuf.TimestampProxy = xdc.useModule('xdc.runtime.Timestamp');

// Create default logger for the whole system.
var LoggerBufParams = new LoggerBuf.Params(); LoggerBufParams.exitFlush = true; Defaults.common$.logger = LoggerBuf.create(LoggerBufParams);

// Turn on USER1 logs in Task module
Task.common$.diags_USER1 = Diags.RUNTIME_ON; // Turn on USER2 logs in Main module (all non-modules)
Main.common$.diags_USER2 = Diags.RUNTIME_ON;

    You can then now use ROV to view the logs using the Logger module.

    Let me know if you have any questions regarding this

    Moses