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

Wait For Interrupt Instruction (WFI) Doesn't Work Right

Victor Chan
Intellectual 765 points
Other Parts Discussed in Thread: OMAP-L138

Hello,

I am using a Mistral EVM with PG1.x version of the DM814x on  a debugger.  My system is running properly until I try using the "wfi" instruction.

The "wfi" instruction does put the ARM to sleep and the next incoming interrupt will wake it  up at the beginning of operation.   But within two minutes or so, the "wfi" will put the ARM CPU to sleep but the next interrupt cannot wake it up.   When I stop the debugger, the PC is always at the address after the "wfi".

I am handling the following interrupts, GP0P23 at 2K Hz, TI UART0, TIMER2 and 3PGSWRINT0.

I checked the errata but there is nothing regarding this issue.

I have successfully implemented the OMAP-L138 version of "wfi" on that CPU and the only difference between that CPU and DM814x is the use of "wfi" instruction instead of a cp15 register.

Any idea on why this isn't working?

Thanks,

Victor

 

  • 0
    TI__Expert 5685 points

    Victor,

    Can you please confirm if you are using 1.x or 2.x rev of the device. Even better, can you please provide the kernel boot log (it will show the version detected)?

    I want to reconfirm this since on 1.x version WFI should not be enabled as it would lead to system hang (as you have observed).

      Hemant

  • 0 in reply to HemantPedanekar
    Intellectual 765 points

    Hello,

    I am not running Linux.   I successfully ported eCos to this CPU so I won't be able to provide the kernel boot log. However, my Mistral EVM (version 1.1) has DDR2  instead of DDR3 which I believe only has 1.x CPU.  If you have a memory mapped address for the die ID on the CPU,  I can easily dump that address.

    Problem appears to be on the interrupt controller.   Enabling AUTOIDLE, TURBO or FUNCIDLE appears to make this problem happens faster or further out.

    Victor

  • 0 in reply to Victor Chan
    Intellectual 765 points

    Hello,

    I read the version of the ROM code at  address 0x4002bffc.  The bytes are  0x01 0x22 0x00 0x00.    So is this a 1.x device?

    I tried  all 8 possible combination of those AUTOIDLE, TURBO and FUNCIDLE bits in the interrupt controller and some combinations allowed the CPU to run more than five minutes.   But eventually,  the CPU will hang up.

    Well,  I hope that you are correct that this WFI bug is only in the 1.x version of the device and fixed on 2.x.

    Please confirm.

    Thanks,

    Victor