Other Parts Discussed in Thread: OMAPL138
Tool/software: TI C/C++ Compiler
I have used the DSP6748 for several years but due to more and more functions implemented in the system I am working on, I had to switch to use the OMAPL138 in order for the DSP to be able to do the work within the time constraints, by moving non-critical tasks to the ARM.
In the previous DSP only system, I had a total of 12 interrupts running with no problems.
In order to move some of the workload from the DSP to the ARM in the OMAPL138, I have kept 7 interrupts in the DSP and moved the interrupts and code for the remaining 5 into the ARM + I have added one more interrupt into the ARM.
The hardware platform is a near copy of the LogicPD OMAPL138 module with the addition of a 6 ch. ADC and a FPGA and related opamps etc. The DSP uses DMA to move data from the ADC and for every 128 samples a hardware interrupt signals the DSP to do filtering and calculations on 6 ADC channels. Max. sample rate is 51kHz, currently 30kHz, divided by 128 gives around 400Hz resp. 235Hz.
I was/am using the Starterware so no RTOS nor Linux is in play.
The allocated stack seems to be sufficient.
Now to my problem/questions:
Sometimes, one of the interrupts in the DSP stops responding. It is always the same interrupt and unfortunately the interrupt that services the ADC, namely the above mentioned hardware interrupt.
The interrupt functions are all as small (fast) as possible.
Any idea why an interrupt can stop working?
Is it unwise to have interrupts in both the ARM and the DSP running concurrently? Can the ARM block an interrupt in the DSP? Or visa versa?
All good ideas/suggestions/hints are highly appreciated.
Cheers,
Claus
