Welcome to the C2000™ Microcontrollers Section of the TI E2E Support Community. Ask questions, share knowledge, explore ideas, and help solve problems with fellow engineers. To post a question, click on the forum tab then "New Post".
I have been testing the F28035 and ran into confusing regarding interrupt response time.
From spru430e.pdf I found a timing in example that implies an 8 cycle response? In interrupt code example files (f. ex.
ACDC_ISR.asm in the ACDC project) from TI the comments say "13
cycles to get here".
Is the interrupt response time really 20 cycles or
should it be something else?
Hardware interrupt latency on Delfino and Piccolo devices is shown in the wiki article here:
(This is from the multi-day workshop)
For an internal interrupt such as PWM timer, there is a minimum of 14 cycles measured from the interrupt arriving at the core to the execute pipeline phase of the first ISR instruction.
If may be setting or clearing an I/O within the ISR to measure the time. This adds additional cycles so to this number must be added the context save added by the compiler. The user guide reference you mentioned shows the additional CPU cycles for a complete context save 14 + 8 = 22. The compiler may add fewer than this, depending on the ISR code and optimisation level. You will see this in the generated assembly code.
By default, interrupts are disabled inside an ISR. If the code has several PWM interrupts the timing will be held out if the interrupt is triggered while one of the other ISRs is running.
This may explain the variation in the timing measurement.
This is for Delfino processor.
What information does the "context save" save for an interrupt? Some reference guide says it automatically save some basic registers in 6 to 7 cycles. However, it does not save RB register and the floating CPU related registers. It's the ISR responsibility to save above information. All the floating registers have shadow registers. If nested interrupt is not supported, then the floating registers can be saved in the shadow registers when entering the ISR. If nested interrupt is supported, the floating registers have to be saved to the stack. In the worst case, the context save may cost more than 40 cycles. Can you clarify above issues? It seems TI's original interrupt mechanism doesn't support nested interrupt. I can manipulate the ISR to enable nested interrupt. What context should I save if I enable the nested interrupt or not?
Also, if enable the nested interrupt, will the "low priority interrupt" interrupt the "high priority interrupt"?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.