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.

Compiler/TMS570LS0432: Question on TI's _gotoCPUIdle_ implementation

Expert 2025 points
Part Number: TMS570LS0432
Other Parts Discussed in Thread: HALCOGEN

Tool/software: TI C/C++ Compiler

There is file sys_core.h from TI's library (some layer, may be HalCoGen generated?), and it declares this method :  _gotoCPUIdle_

From dissassembly, I see that method basically calls __wfi, followed by 4  nop's.   Basically this:

_gotoCPUIdle_

        WFI
        nop
        nop
        nop
        nop
        bx    lr

    .endasmfunc

I'm a bit puzzled, why nop's are needed here, and why 4?  ( Was trying to relate this to pipline length/stages,  but doens't match on this MCU).

  • Hello,

    Please refer to the feedback in this thread:

  • Hi  

    Thank you for the link to that discussion.

    I don't think I understand the accepted answer,  esp part . "i.e., it provides a buffer between the WFI command and the bx lr instruction. Otherwise, the bx lr instruction would keep the CPU from halting and the function call would simply return and continue execution.. ".

    Would really appreciate if someone explains this. Which ARM manual (or TI's ?) this is explained , esp  "..otherwise the bx lr would keep CPU from halting". 

    The  cortexr4_r1p3 manual (see full name on that thread) says  (also per that thread ..) doesn't look to have those details  (see thread ). Note that is says : " ..the WFI automatically performs a Data Synchronization Barrier operation"

    The ARM v7 and ARM-v7-R  Arch reference manual (same doc) , says :  "When a processor issues a WFI instruction it can suspend execution and enter a low-power state. "     

    Seems like then it can suspend execution immediately after the automatic DSB.

    Why would bx lr  which is following WFI prevent CPU immediately entering lp? 

    Confusing part is that the Arch manual also says " .. The WFI instruction provides a hint  .. "   So by that,  I could interpret that it's not guaranteed that it will always fall  a sleep. (bah !)

    (Not to mention that they also say waking up is Implementation Defined ..)

  • Hello,

    I was not involved in the code development of HALCoGen, so I don't have insight into the decisions of adding NOPs after WFI. 

    As mentioned in your post, WFI automatically performs a Data Synchronization Barrier operation. So when a WFI instruction is executed, the Cortex-R5F core flushes its pipeline, flushes all write buffers, and completes all pending bus transactions. My understanding is that the "nop" is not a MUST after WFI. I am looking forward to seeing more inputs from experts.