TMS320F28075: ISR register save with FPU, TMU (R4H to R7H, XAR3?)

Hi Frank,

I dont see  --float_support=fpu32 in your compiler flags. Could that be the reason?

-Shantanu

Hi Shantanu,

I do not believe that this is the reason. I am sorry, I copied the compiler flags out of CCS while playing around with the --fpu32 and --tmu0 options. It seems that --tmu0 implies --fpu32 (I cannot switch off --fpu32 when --tmu0 is on, see screenshot, but in the flag list I copied from, --fpu32 disappears).

Anyway, the code generated is the same in both cases (with saving R0H to R3H, etc.), and the my question regarding the other registers is still the same.

Thanks & regards,

Frank

Hi Frank,

Yes you are right about the flags. The FPU overflow interrupt takes place in case of an LVF flag, which is only triggered by math operations. 

XAR3 should ideally be saved during the context save and we need to investigate why that is. R4H to R7H are not generally saved. 

But if the interrupt being generated is 12.7, you need to trace the STF register and identify the exact point at which the interrupt is being generated. Can you assembly step through the code and let me know the exact point at which the interrupt is being generated?

-Shantanu

Hi Shantanu,

thank you for your support. We'll try to reproduce the error, seems difficult to catch it.

Do you have any news concerning the register saves meanwhile?

Thanks & regards,

Frank

Hi Frank,

High priority interrupts use fast context saves, which leads to only essential registers being saved. This is probably why you're observing less number of registers being saved. Can you try making it a low priority interrupt and let me know what you observe?

-Shantanu

Hi Shantanu,

I don't know how to make it alow low priority interrupt, IMHO on the C28xx CPU there is only one level for the masked interrupts. Sure there are different levels of register save: If I use an assembler routine, I am myself responsible to save the registers that are not saved automatically (Table 3.4 in SPRU430F), and if the C-ISR does not call any other function, the compiler might decide not to save registers not used. But as soon as there is any funcition call in the ISR (as in my example), I think all the registers that the compiler might use have to be saved.

Thanks & regards,

Frank

Frank,

PLease check out this wiki: https://software-dl.ti.com/C2000/docs/c28x_interrupt_nesting/html/index.html#Example:_Using_Mask_Values_to_Manage_the_Prioritization

and also these threads:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/365915/changing-interrupt-priority

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/21591/tms320f28335-fpu-full-context-save-restore

-Shantanu

Hi Shantanu,

thanks for the interesting links. IMHO, the PIE / PIEIER things and priorities do not influence the CPU / FPU register save / restore.

But I tried the #pragma INTERRUPT (cpu_timer0_isr, LPI | HPI), and indeed, the save / restore is different, details see below. FPU manual SPRUHS1B says that SAVE / RESTORE R0H to R7H to / from shadow registers, this is for high priority ISRs (HPI) that cannot be nested. Unfortunately, the #pragma does not prevent that the user programs nesting. OK, there is a warning in the compiler manual SPRU514P.

But in our case we want nested ISRs, so the default setting LPI is the correct one (save FPU registers on stack).

So, I am still wondering what with R4H to R7H and XAR3 (and TMU?). If the compiler never uses them, all is fine, and we have to search for other reasons. Otherwise, it's a miracle that so many programs run...

Thanks & regards,

Frank

Here the disassemblies for high and low priority ISRs:

HPI:

013da6:   761B        ASP          
013da7:   0005        PUSH         AR1H:AR0H
013da8:   ABBD        MOVL         *SP++, XT
013da9:   AABD        MOVL         *SP++, XAR2
013daa:   A8BD        MOVL         *SP++, XAR4
013dab:   A0BD        MOVL         *SP++, XAR5
013dac:   C2BD        MOVL         *SP++, XAR6
013dad:   C3BD        MOVL         *SP++, XAR7
013dae:   FFF0        PUSH         RB
013daf:   E6700600    SAVE         RNDF32=1,RNDF64=1
013db1:   FF69        SPM          #0
013db2:   2942        CLRC         OVM|PAGE0
013db3:   5616        CLRC         AMODE
013db4:   761F0030    MOVW         DP, #0x30

...

013e7b:   E562        RESTORE      
013e7c:   FFF1        POP          RB
013e7d:   C5BE        MOVL         XAR7, *--SP
013e7e:   C4BE        MOVL         XAR6, *--SP
013e7f:   83BE        MOVL         XAR5, *--SP
013e80:   8ABE        MOVL         XAR4, *--SP
013e81:   86BE        MOVL         XAR2, *--SP
013e82:   87BE        MOVL         XT, *--SP
013e83:   0003        POP          AR1H:AR0H
013e84:   7617        NASP         
013e85:   7602        IRET        

LPI:

013da6:   761B        ASP          
013da7:   FFF0        PUSH         RB
013da8:   0005        PUSH         AR1H:AR0H
013da9:   ABBD        MOVL         *SP++, XT
013daa:   AABD        MOVL         *SP++, XAR2
013dab:   A8BD        MOVL         *SP++, XAR4
013dac:   A0BD        MOVL         *SP++, XAR5
013dad:   C2BD        MOVL         *SP++, XAR6
013dae:   C3BD        MOVL         *SP++, XAR7
013daf:   E20000BD    MOV32        *SP++, STF
013db1:   E20300BD    MOV32        *SP++, R0H
013db3:   E20301BD    MOV32        *SP++, R1H
013db5:   E20302BD    MOV32        *SP++, R2H
013db7:   E20303BD    MOV32        *SP++, R3H
013db9:   E6300600    SETFLG       RNDF32=1,RNDF64=1
013dbb:   FF69        SPM          #0
013dbc:   2942        CLRC         OVM|PAGE0
013dbd:   5616        CLRC         AMODE
013dbe:   761F0030    MOVW         DP, #0x30

...

013e85:   E2AF03BE    MOV32        R3H, *--SP, UNCF
013e87:   E2AF02BE    MOV32        R2H, *--SP, UNCF
013e89:   E2AF01BE    MOV32        R1H, *--SP, UNCF
013e8b:   E2AF00BE    MOV32        R0H, *--SP, UNCF
013e8d:   E28000BE    MOV32        STF, *--SP
013e8f:   C5BE        MOVL         XAR7, *--SP
013e90:   C4BE        MOVL         XAR6, *--SP
013e91:   83BE        MOVL         XAR5, *--SP
013e92:   8ABE        MOVL         XAR4, *--SP
013e93:   86BE        MOVL         XAR2, *--SP
013e94:   87BE        MOVL         XT, *--SP
013e95:   0003        POP          AR1H:AR0H
013e96:   3B30        SETC         INTM|DBGM
013e97:   FFF1        POP          RB
013e98:   7617        NASP         
013e99:   7602        IRET

Frank,

I wonder if this is a function of the optimisation. Can you revert the optimisation levels to off and do not optimise for code size? If the compiler senses that the XAR3 is not being used, it may not save it. 

-Shantanu

Shantanu,

I think this cannot be a function of optmisation (-Ox flag), if there are function calls in the ISR. These functions may be compiled with different optimisation (e.g. in a library) the compiler actually does not know about.

Thanks & regards,

Frank