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

L138 & NDK interrupt latency

Ricardo Leber1
Prodigy 220 points
Other Parts Discussed in Thread: OMAPL138

Hi,

We have a LCDKL138 kit and we have executed firmware that uses the McASP through interruptions without any problem at all. We have also used a basic firmware with the NDK v.2.22.3.20 without any inconvinience. The problem is when we try to combine both firmware. We have noticed that the transmit under run condition (bit 0 of the XTAT) is set so the McASP stops working a couple of seconds after launching the program. We think this is because the NDK stack introduces an excessive latency on the service of the interrupts. Could someone guide us how to solve this problem?

Thanks in advance.

  • 0
    TI__Guru** 116100 points

    Hi Ricardo,

    How did you configured the McASP ?

    I have heard that OMAPL138 had problem with McASP "under run" issue.

    I will get back to you on this.

  • 0
    TI__Mastermind 35645 points

    Hi,

    Thanks for your post.

    In general, servicing any external peripheral's interrupt request wouldn't get delayed due to introducing NDK stack, may be, if any high priority task is being requested by EMAC peripheral to EDMA introduced in the NDK application would introduce a typical latency and this all depends on the priority assignment determined in the Master Priority Registers (MSTPRI0-MSTPRI2) in the System Configuration Module where each master has an allocated priority value (power on reset default value), which can be re programmed based on the applications prioritization requirements.

    When multiple masters are trying to access common shared resources (slave memory or peripherals), the priority value allows the system interconnect to arbitrate requests from different masters based on their priority. I would recommend you to configure the EDMA3TC priority which would be controlled by the QUEPRI register in the EDMA3CC memory-map. However for this device, the priority control for the transfer controllers is controlled by the chip-level registers in the System Configuration Module. For more details, please refer section 18.2.13 for EDMA3 prioritization in the OMAPL138 TRM as below:

    http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf

    In my guess, after combining NDK application with McASP application, the EDMA would be serving very large EMAC packet size which wouldn't meet the expected time to transmit for larger packet sizes and it would have introduced memory latency to transmit the huge tx. packets and this would have caused to stall the McASP interrupt service, thereby, the XRBUF of McASP's serializer wouldn't be loaded with any new data since the last transfer after the state machines are released out of reset. This would have caused the McASP transmit underrun issue to occur.

    Please consider the EDMA priority assignments to be reprogrammed in the SYSCFT module after introducing the NDK's EMAC application with McASP application

    Thanks & regards,

    Sivaraj K

    ------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question

    -------------------------------------------------------------------------------------------------------

  • 0 in reply to Sivaraj Kuppuraj
    Prodigy 220 points

    Thanks for your quick answer,

           We will test what you have told us, and well reply when we have the results.

    Regards

    Ricardo