• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 97 subscribers
  • Views 995 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.

SIO reclaim takes too long

ReinierC
Expert 2425 points

Good day experts,

My setup is as follows:

- C6748 DSP clocked at 456MHz

- DSP/BIOS 5.42.01.09

- BIOSPSP drivers v1.30.01

- CCS 5.4

- EDMA3 LLD v1.11.03.01

- AIC3204 audio codec

I believe we are having some CPU load issues, but I am struggling to properly narrow it down to the culprit. I did some timing measurements, and the first thing that struck me was the execution time of the SIO_reclaim() when getting audio samples from input stream.  I configured the codec for a sampling rate of 9600 Hz, but I would occasionally measure that SIO_reclaim() takes up to 150+ ms to complete, much longer that I would expect. Some more information about the audio stream setup:

- The input and output stream are both primed with 8 buffers of 160 bytes, which are allocated from internal RAM are also correctly aligned.

- SIO_reclaim() is called from the task with the highest priority

- Besides the I2C0, McASP and EDMA, the only other peripherals that are significantly used are UART0 (115200 baud) and UART1 (9600 baud).

- I2C0, McASP and EDMA interrupts are through the event combined module on HWIs 7,8,9 and 10

- UART0 and UART1 are configured on HWI 13 and 15 respectively and are only configured for receiver interrupts. UART transmissions occur in normal tasks with lower priorities than the SIO_reclaim() task.

Basically only HWIs and SWIs can pre-empt a SIO_reclaim() call. I know the call is blocking and yields until it receives a full buffer, but that should at most only take a couple of milliseconds, not in the region of 100+ ms! I've configured the UART peripherals only to interrupt when the receiver FIFO reaches 14 bytes (the maximum level), so that it does not interrupt too frequently.

This problem that I've been seeing only occurs when I'm actually using UART1, so I measured the ISR execution times on a scope:

- The execution time is no longer than 2 us (microseconds)

- The frequency of UART1 interrupts is about 2.4 ms

- Bursts of data are periodically received on UART1, which results in interrupts roughly every 2.4 ms for 54 ms

So my question is thus, do you have any idea what can cause SIO_reclaim() to block for so long?

Thanks in advance!

Regards

  Reinier

  • 0
    TI__Mastermind 45025 points

    Hi Reinier,

    Can you please provide the details of your SIO_issue() calls in your program?

    Can you please double check in your app that the following conditions are being met? Particularly, the items that are bolded?

    The stream must be created with attrs.model set to
    SIO_ISSUERECLAIM.

    ❏ There must be at least one outstanding SIO_issue when an
    SIO_reclaim call is made.

    ❏ SIO_reclaim returns an error if it is called from a SWI when no buffer
    is available. SIO_reclaim does not block if called from a SWI.

    ❏ All frames issued to a stream must be reclaimed before closing the
    stream.

    ❏ SIO_reclaim cannot be called from a HWI.

    ❏ This API is callable from the program’s main() function only if the
    stream's configured timeout attribute is 0, or if it is certain that there
    is a buffer available to be returned.

    Steve

  • 0 in reply to Steven Connell
    Expert 2425 points

    Hi Steve,

    I'm not exactly sure what kind of details you are looking for, can you be a bit more specific?

    I have two audio interface tasks, one for the input stream and one for the output stream. The task associated with the input stream has the highest priority in the system and the task associated with the output stream has the second highest priority. The input stream essentially just gets the audio sample from the input stream and buffer it for lower priority tasks to do the processing. The output stream essentially just gets the audio samples to be transmitted from a buffer and gives it to the SIO stream for transmission. The SIO_reclaim() function is always called first in the tasks, followed by a SIO_issue() call since both streams were primed before task execution, i.e. the calls are balanced.

    I can confirm that all of the conditions you mentioned are indeed met, I believe this comes from the DSP/BIOS user guide and API reference?

    As I mentioned in my previous post, something is blocking SIO_reclaim() longer than it should, and it can only be HWIs or SWIs or maybe something else within DSP/BIOS.

  • 0 in reply to ReinierC
    TI__Mastermind 45025 points

    Hi ReinierC,

    Yes, I wanted to make sure that the calls to SIO issue/reclaim were balanced.  I was suspecting that your SIO_reclaim() call (in higher pri task) was being held up waiting for an SIO_issue() call in a lower pri task.

    Are you able to halt the application at the point that SIO_reclaim is blocking for longer than you expect?  If so, please halt it and bring up ROV at this point.  You should be able to see some information about what's currently running in the system.

    Steve

  • 0 in reply to Steven Connell
    Expert 2425 points

    Hi Steve,

    Thank you for you response.

    I'm afraid I do not have an easy way of stopping it midway through execution, based on a timing threshold, but I think I can figure something out. However, a more serious problem is that my ROV is not working properly in CCS5 in anymore. When I select RTOS Analyzer -> RTA (Legacy) -> Raw Log / Printf logs / CPU load etc, the tabs are opened but I simply do not see any logs. Do you know what may be wrong?

    Regards

  • 0 in reply to ReinierC
    TI__Mastermind 45025 points

    Reinier,

    But are you able to see ROV?  (I know it's confusing, but ROV - the object viewer used when the app is halted - is different than the RTOS Analyzer - which is used at run time or when halted).

    ROV allows you to see things like the tasks, semaphores, etc., basically kernel objects that you have in your system and their states at the current point in the program (where halted).  It's also in the tools menu of CCS.

    Steve

  • 0 in reply to Steven Connell
    Expert 2425 points

    Hi Steve,

    Sorry for the delayed response.

    I checked again, I was indeed confused with ROV and RTOS Analyzer. I am able to view the objects from ROV when a program is halted. Are there specific things that I should look out for, that can provide me with more information?

    Regards

      Reinier

  • 0 in reply to ReinierC
    TI__Mastermind 45025 points

    Reinier,

    Yes, ROV will provide lots of useful info about the state of your application.  For example, it will tell you info about tasks you have in your app, such as their stack size, stack peak, state (is it running? or blocked?), etc.  I think the "blocked on" feature may help you here.

    For example, you could halt the program and you may see that your SIO task is blocked.  ROV might tell you what it is blocked on (most likely a semaphore).  You could use that information to find out which semaphore it's waiting for.  Then investigate that semaphore ... why is it unavailable?  Who has the semaphore?  Why do they have it for so long?  And so on.  Hopefully this will lead you to the cause of the problem.

    For more info on ROV, please see the DSP/BIOS User's Guide chaphter "3.3 RTOS Object Viewer (ROV)".

    Steve