• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 1173 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/TMS320F28069: PIE: Spurious Nested Interrupt fix in TI-RTOS kernel

Joseph Chang
Expert 1170 points
Part Number: TMS320F28069

Tool/software: TI-RTOS

While reviewing the TMS320F28069 Silicon Errata (sprz342k), I saw the usage note 4.1.1 "PIE: Spurious Nested Interrupt After Back-to-Back PIEACK Write and Manual CPU Interrupt Mask Clear".  I'm using TI-RTOS, which means that the TI-RTOS kernel is responsible for acknowledging the PIE.  I assume that kernel has this fix, but I was wondering are there were versions of TI-RTOS kernel with this fix?  If so, in which version of TI-RTOS was it fixed?  It would be helpful to know when the fix was introduced to check if an existing application is using a versions with or without the fix.

Thanks,

Joseph

  • 0
    TI__Guru* 96960 points
    Nothing jumped out in the bug tracking software. I'll check with the team to see if this errata impacted our scheduler code on C28069.

    Todd
  • 0
    TI__Mastermind 18260 points

    In looking at the latest SYS/BIOS kernel code for C28 devices, I don't believe any of it uses the problematic code sequence as shown in the errata.

    The errata is very specific about the sequence:

    1. A write to the PIEACK register
    2. A "CLRC INTM" in the very next cycle

    The "CLRC INTM" instruction hard-enables interrupts.  SYS/BIOS doesn't do hard-enables, and instead it does disable/restore operations (using _disable_interrupts()/_restore_interrupts()).  The "restore" is basically a "POP ST1", which is not a "CLRC INTM" instruction, so I believe there is no need for SYS/BIOS to have this fix.

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Expert 1170 points

    Hi Rob,

    Thanks for checking the latest SYS/BIOS kernel code.  Could you check for TI-RTOS for C2000 2.12.1.33?  Spurious nested interrupts may explain a difficult to reproduce issue, so knowing if 2.12.1.33 specifically does or does not have the issue would help tremendously.

    Best Regards,

    Joseph

  • 0 in reply to Joseph Chang
    TI__Mastermind 18260 points

    I'm sorry to hear you're having a difficult-to-reproduce issue.

    The SYS/BIOS in TI-RTOS 2.12.1.33 is version 6.41.04.54.  I looked at the Hwi code for C28 in there and it is essentially the same as the newer version that I inspected previously, with the only difference being things unrelated to PIEACK and interrupt enabling.

    So my previous statement for the newer SYS/BIOS applies to this older version as well - SYS/BIOS won't contain any "CLRC INTM" instructions at all (except for possibly where it enables interrupts for the very first time, in boot code), and just does __disable_interrupts() and __restore_interrupts() which use different code sequences than the problematic one in the errata.

    One thing you could do to verify this for yourself is to diassemble your executable file, using the 'dis2000' tool in the C28x TI compiler.  It should be fairly simple to search for all instructions involving "CLRC INTM" and to see if any PIEACK writes precede them.

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Expert 1170 points

    Thanks for checking the previous version and pointing me to 'dis2000'.

    I tried 'dis2000' and found that all instances of CLR INTM were preceded by PUSH ST1, such as:

    003ef32d   7608   PUSH         ST1
003ef32e   2930   CLRC         INTM|DBGM

    For comparison, this is the assembly when I generated the problematic code:

    ;----------------------------------------------------------------------
;  42 | PieCtrlRegs.PIEACK.all = 0xFFFF;                                       
;----------------------------------------------------------------------
        MOVW      DP,#_PieCtrlRegs+1    ; [CPU_U] 
        MOV       @_PieCtrlRegs+1,#65535 ; [CPU_] |42| 
	.dwpsn	file "test.c",line 43,column 5,is_stmt,isa 0
;----------------------------------------------------------------------
;  43 | EINT;                                                                  
;----------------------------------------------------------------------
 clrc INTM

    While it doesn't explain my problem, it does help rule this out.

    Best Regards,

    Joseph