Floating Point Unit context save

Hi,
As far as I know, we have to save the CPU registers (program context) and all interrupts must be disabled to avoid re-entrancy, before ISR call and need to restore the CPU registers and enable all the interrupts, after ISR call.
I would like you to use the following examples which has ISR programming for GPIO interrupts in ARM and DSP.
I hope, this program would do everything for you.

C:\ti\quickStartOMAPL1x_rCSL\OMAPL1x\rCSL_examples\evmOMAPL137\ARM_examples\gpio\GPIO_multi_led_interrupt_armL137\src
C:\ti\quickStartOMAPL1x_rCSL\OMAPL1x\rCSL_examples\evmOMAPL137\DSP_examples\gpio\GPIO_multi_led_interrupt_dspL137\src

Hi,
thanks for your kind reply!
About the link you posted: how to download the files? They seem to pint to a local path on you HD.
About the interrupt routine:
- I suspect that maybe I should use the lock/unlock (they are at the default value _nop right now) routine because I think the C runtime environment is not re-entrant.
On this snippet of code, I see a wrong division result:
ul[0]=cnc_handle.ul_counter_clock; //saves the interrupt counter
*dblT1=fabs(dblAmax/dblJerk); // this should give 20.0
if (*dblT1==16)
{
__asm(" nop 10"); //wow! when this happens, the interrupt counter is different from the saved value, so I think the interrupt has ruined the float environment
}


So i think the C runtime is disrupted by the interrupt routine and to avoid this I should register the lock/unlock routines:
- am I correct in your opinion?
- have you any example of lock/unlock routine I can use?

Many many thanks for your help!

Hi,
You can get that package from the following link.
processors.wiki.ti.com/.../QuickStartOMAPL1x_rCSL

Always, try to use less no of lines of code in ISR routine and don't use any library APIs etc., (Just short and simple, this is the main rule of ISR)

HI Titus,
thanks for your link.
Anyway my interrupt routine should execute trajectory interpolation for a CNC board, so the ISR is quite big...
Have you any link to a lock/unlock implementation?
Thanks

HI Titus sorry for bothering you again!
Have you any idea about the reason that my code snippet won't work when an interrupt occurs?
- My interrupt routine saves a0-a9 and b0-b9 (automatic from the compiler);
- I save and restore the fadcr faucr fmcr registers too

But the line of code:
*pdbl_pointer=fabs(double_1/double_2)
fails giving the incorrect result when the interrupt routine happens while executing the fabs+div_d operation: as stated, the expected result is 20.0, but I read 16.0.
If i repeat the execution moving back the program counter, then it gives the correct result, so I think it's the interrupt routine which disrupts some floating point environment.
I looked at the div_d implementation and at this moment I see no static variables etc so even the lock/unlock won't be useful.
The fabs becomes a single FPU instruction, no routine involved so I think it's not affected by the interrupt routine
Have you any idea?
Are there any further register I should save/restore in the interrupt routine or maybe is the lack of lock/unlock that gives the problem?
Many thanks!

Hi, I noted just now that on my project (imported from CCs3.3) the target processor was set to C6713; now I have set it to back to C6740 (-mv6740):
- now I am out of office until next Monday; do you think this can explain the strange behavior of the OMAP?

Update: using the compilation switch -mv6740 today so far no double calculation errors after a couple of hours trial test. The errors were arising in a random manner, so I am not sure that is solved.
I'll keep you updated.
After I changed the compilation switch, the prologue/epilogue of the interrupt routine automagically changed including the C674x registers as described in the compiler app note, and furthermore the linker included a different library... so a lot of things changed in the code and now I am trying with a completely different binary code.

Have you any idea if the incorrect setting of the silicon CPU type can give errors when working with interrupt and floating points?
Many thanks

Well yeah me too I noticed that a new CCS project uses the correct silicon version, but my project was imported from a legacy CCS3.3 old project, where the 6740 option wasn't present in the project droplist.
Update of the trial test: 4 hours of test, restarted once the whole system just to check if the problem arises depending upon the startup state, no problems so far.
I would ask you if you can keep this thread open until next week, and if you can be so graceful to assist me the first days of the next week in case of need: your help is very useful for me.
About the CCS folks: do you think it would be better for me to post a question about the current issue in the CCS forum too?
Thanks!