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

TMS320F280049: Will Flash module on/off affects the ISR on RAM?

Wayne Huang
Genius 17125 points

Part Number: TMS320F280049

Champs.

I am asking this for our customer.

If there is an interrupt trigger happens when the flash module goes from sleep/standby to active mode, will the interrupt be served immediately as usual or will it be served after the flash module is back to the active mode?

The ISR codes are all on the RAM.

Wayne Huang

  • 0
    TI__Expert 6795 points
    Hi,

    Is the whole program is in RAM or FLASH? Are there any sections of code which is copied from Flash to RAM?

    As per my knowledge, if the whole code is placed in RAM, the Flash dependency shouldn't be there.

    Anyhow I will check other Flash experts and get back to you.

    Thanks,
    Katta
  • 0 in reply to Rajaravi Krishna Katta
    TI__Genius 17125 points
    Katta,

    In this case, only some background codes are in flash. Other codes including ISR are all copied from flash to RAM and running on RAM. Peripherals and the associated clocks for ISR triggering are running actively. Therefore, the user wonders if ISR (triggering, latency , execution) will be impacted by the flash mode changes when only background loop has dependency on flash.

    Wayne
  • 0 in reply to Wayne Huang
    TI__Guru* 87155 points
    Wayne,

    If the ISR is mapped to RAM for execution, Flash power mode changes should not have any effect.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    TI__Genius 17125 points
    Vamsi,

    In the user's case, they found the ISR was delayed.
    Their background code has codes for flash power mode change.


    We just noticed that in
    sec 3.12.6.1 of F28004x TRM (www.ti.com/.../sprui33b.pdf)
    has such descriptions

    Sleep State
    This is the state after a device reset. In this state, a CPU data read or opcode fetch will automatically
    initiate a change in power mode to the standby state and then to the active state. During this transition
    time to the active state, the CPU will automatically be stalled.
    • Standby State
    This state uses more power than the sleep state, but takes a shorter time to transition to the active or
    read state. In this state, a CPU data read or opcode fetch will automatically initiate a change in power
    mode to the active state. During this transition time to the active state, the CPU will automatically be
    stalled. Once the flash/OTP has reached the active state, the CPU access will complete as normal.


    From the above two, the CPU will be stalled during flash transition from sleep/standby to active state.
    This matches the user's experiments.

    Would you please doubly check if this is true that the flash power mode change (sleep/standby->active states) on background codes will cause CPU to be stalled so that the ISR execution will be delayed?

    Wayne Huang
  • 0 in reply to Wayne Huang
    TI__Guru* 87155 points

    Wayne,

    When there is an access by CPU to Flash for data or code, it will get stalled until the power mode is back to active.

    That is what I meant in that TRM text. I can confirm with spec/design on the same, if needed.

    You mentioned there is some background code task in Flash - Does interrupt triggering depend on that background code in this case? 

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Guru* 87155 points

    Wayne,

    Also, take a look at section 3.10.4 Flash Power-down Considerations in TRM (http://www.ti.com/lit/ug/sprui33b/sprui33b.pdf ).

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Genius 17125 points
    Vamsi,

    In this case, the ISR (on RAM) is triggered by ADCINT1, and is purely by hardware.
    There is flash power mode switch code on the background code.
    The user found the ISR is delayed at the frequency similar to background code rather than the ISR frequency.
    In above discussions, it seems ISR is delayed because the background codes access the flash and try to change the mode from sleep/standby to active, and thus CPU is stalled and cause a delay to serve the ISR, which leads to an unexpected behavior in the user’s case.
    Is our understanding correct?


    Wayne
  • 0 in reply to Wayne Huang
    TI__Guru* 87155 points

    Wayne,

    Yes, your understanding is correct. If the background code is accessing the Flash, then there will be a delay from Flash power mode transition.

    One thing to note: Reason I asked you to read section 3.10.4 Flash Power-down Considerations in TRM is that the application software must change the Flash Fallback mode to the Active state when it wants the Flash to remain in active mode. If the application puts the Flash in sleep state, any Flash access will initiate the Flash power transition from sleep to active. However, after the grace period is over, if the Flash Fallback mode is not configured for active mode, Flash will again go back to the configured Fallback mode (FBFALLBACK register).

    Thanks and regards,
    Vamsi