• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 82 subscribers
  • Views 447 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.

TMS320F28069: EALLOW state when entering an ISR?

James McLaughlin
Expert 1090 points
Part Number: TMS320F28069


According to both the TRM and the CPU and Instruction Set documentation for this device, EALLOW should be disabled when entering an ISR (at least see Figure 1-94 of SPRUH18G).  We have many ISRs that do not call EALLOW, but seem to still be able to write to EALLOW-protected registers, specifically the PieCtrlRegs (but also peripheral specific ones).  The only time we've encountered a problem so far is specifically calling EDIS before the end of an interrupt (before writing to the EALLOW-protected registers).

I halted in debug mode within one of these ISRs (the very first line) and EALLOW is indeed enabled, even when we do not call EALLOW.

Why is there a difference between the perceived behavior and the documentation?

Is it just some sort of initialization or configuration we've done that can ignore this protection while in an ISR?

Or set EALLOW to enabled instead of disabled when entering an ISR, or something else?

Thanks!

  • 0
    Expert 1090 points
    The specific register that seems to be an issue is the HRCap2 HCICLR. It's not documented as EALLOW protected, but it seems to require it. Is there a chance it actually is but just not properly documented? I see that the HRCap2 HCCTL register is EALLOW protected.

    This is not an issue for an interrupt that has similar behavior for ECap2 (no EALLOW called, it's actually specifically disabled, but the ECCLR register and the PIEACK registers used both work fine.

    After reading more I see the PieCtrlRegs are not actually EALLOW-protected, it's just the PIE vector table. That might explain why interrupts without EALLOW called work fine (although there's still the open question of why EALLOW seemed enabled in my debug case).
  • 0 in reply to James McLaughlin
    TI__Mastermind 27200 points
    Thanks for reporting this. I see that HCICLR seems to be affected by EALLOW on this device, which is not as documented. I will look into this further and come back to you.

    In all my testcases I'm not able to find interrupt where EALLOW is 1 on entry. All I'm doing is setting a BP on the first line of C code in the ISR and inspecting the ST1 register - EALLOW is always 0 in my case. This is the expected condition as EALLOW is forced to 0 by hardware on interrupt. Can you give me a little more information about the ISR where you see this, or if possible and even better, a compact test case where I can reproduce it? Thanks.

    Regards,

    Richard
  • 0 in reply to Richard Poley
    Expert 1090 points

    Thanks for confirming HCICLR is EALLOW protected after all!  Do you know of any others that may be like this?

    For the EALLOW 1 inside an ISR, it is our ADCINT1 ISR.  I just retested to confirm it and it doesn't appear it's doing that now, though.  I'll keep an eye on it.

  • 0 in reply to James McLaughlin
    TI__Mastermind 27200 points
    Just to let you know we are working on the EALLOW status of other registers and will confirm soon. Thanks for your patience.

    Regards,

    Richard
  • 0 in reply to Richard Poley
    TI__Mastermind 27200 points

    The response from design was the HCICLR and HCIFRC registers are EALLOW protected on F28069, but not so marked in the TRM.  These have been marked for correction in the next release of the document.  Thank you again for reporting it.

    Regards,

    Richard

  • 0 in reply to Richard Poley
    Expert 1090 points

    Ok great, thanks so much for confirming that!