• Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 802 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.

Stable ISR latency and TI specific power management (PRCM)

Kuzmin Alexey
Intellectual 430 points
Other Parts Discussed in Thread: DM3730, OMAP3530

Hello,

My question about ISR latency of TI under WinCE.
I can't found ability to make stable ISR starting time on EVM board with DM3730 module. And I still looked for it.
We are using Adeneo latest Windows CE 6.0 BSP for OMAP/AM35xx/DM37xx processor modules (version BSP_WINCE_ARM_A8_01_02_00_Source)
We found already that the extended TI PM have affected to ISR and make unpredictable ISR start delays. Therefore, additional CPU specific PM "PMExt" disabled completely in WinCE OS design. Just "Power management Full" enabled on "Core OS services".
Also, There is minimal other interrupt sources which can affect to ISR processing. And we control it for minimal activity.
ISR time measurement made by oscilloscope and ISR time vary from 5 to 700 us.
The only way to correct ISR behaivior is manuall replacement of g_wakeupLatencyConstraintTickCount to [1-5] value instead MAX_INT.
It make ISR average time better, but not help make stable maximum time. It isn't solution.
Our goal is stable ISR latency <100us all time OS runnning. Any advices how to make it?

UPDATE: I'm newbie with TI specific power management, don't make attention

  • Intellectual 430 points

    I know too many Holidays in US, but really need help for this topic!

  • in reply to Kuzmin Alexey
    TI__Expert 5320 points

    1. Do you have any catalog items selected under Third Party->BSP->EVM_OMAP3530:ARMV4I->Drivers->PM (such as CPU load policy, DVFS, etc)? If yes, then please disable all for now.

    2. If you disable PMExt also, then suspend resume functionality will not work - I am not sure if you care about it or not.

    3.  By setting g_wakeupLatencyConstraintTickCount to 1-5, the system may never go to Idle (most of the time it will exit out of OEMIdle function without executing WFI).

    4. Did you try using kernel tracker and see what threads/activities are causing delay in ISR?

    5. How are you measuring the ISR latency (I mean, between which 2 testpoints)?

    -Madhvi

  • in reply to Madhvi
    Intellectual 430 points

    Thank you for reply, Madhvi.

    1. I'm disable all PM already in catalog as I noted at first message.

    2. It's same for me at this moment. The stable ISR latency is more requred.

    3. g_wakeupLatencyConstraintTickCount tested from 1 to 3, but i see ISR latencyes, which not stable by time. :(

    4. I didn't, but ISR start can't be delay by any thread activity. Interrupt is interrupt, Am I right? :) I will, but unsure about any results.

    5. Yes we have 2 testpoints. One is HW line of connected device, second is OEMInterruptHandler enter. Also we looked to third testpoint (OEMInterruptHandler exit) and see fast ISR responce time.

    Do you know how better operate with g_wakeupLatencyConstraintTickCount ? How to disable PM completly?

  • in reply to Kuzmin Alexey
    TI__Expert 5320 points

    Kuzmin Alexey said:
    I didn't, but ISR start can't be delay by any thread activity. Interrupt is interrupt, Am I right? :) I will, but unsure about any results.

    If there is thread running for a long time with interrupts disabled, then you will see a delay in ISR start - that's the type of activity kernel tracker can show us. Don't forget to enable profiler and all celog zones in your build.

    Kuzmin Alexey said:
    Do you know how better operate with g_wakeupLatencyConstraintTickCount ? How to disable PM completly?

    You have disabled all the optional components from BSP. To disable PM even further, you will have to remove the Microsoft PM component as well - although I am not 100% confident if this will completely remove all the PM - worth a try. Alternatively, you can comment out everything inside OEMIdle() and see if this is adding to the varied ISR latency timings.

    -Madhvi

  • in reply to Madhvi
    Prodigy 40 points

    Commenting out OEMIdle() internals does the job!

    I faced with the same issue and spent about a week implementing interrupt processing first in OEMInterruptHandler then same for FIQ.

    Finally looking at the scope on the pulse generated using OALStall(1) I noticed that it is 2 times wider in case of late interrupt.

    So when I ran while(1) on user mode it gave me stable picture, no late irqs.

    Thanks to all who posted to the thread.

  • in reply to Sergey Venkov
    Intellectual 430 points

    ...do job, but kill battery life! :)

  • in reply to Kuzmin Alexey
    Prodigy 40 points

    I work on "always on" device, so I don't care about batteries.