- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Part Number: TMDSPREX28335
Tool/software: Code Composer Studio
This simple setup is used to measure interrupt latency and jitter for different configurations (non-OS, running from RAM, running from FLASH, RTOS Hwi, RTOS Swi, zero latency etc...)
A single breakpoint, placed at entry point of XINT1 IRQ handler has been configured to skip the first 5 counts, then the debugger should go into "Remain Halted"!
This results in: (copy-pasted from CCS7 "Breakpoints-view")When I set a second breakpoint in XINT1 IRQ handler without configuring a skip-count for the second one, the debug session break sequence is as follows:
(...inf Resumes...)
The only thing I can do to "Re-Arm" the breakpoint on line 120 is a disable/enable sequence:
What am I missing regarding breakpoint behavior in case of using a TI-RTOS setup?
Best regards,
Manuel
----
I haven't yet repeated the "skip-count" problem with a TI-RTOS setup, but initially went to check the breakpoint skip-count with a non-OS example. I used the external_interrupt example from controlSUITE for a TMS320F28335 which is similar to your described code in that it is designed to measure interrupt latency by using externally connected GPIOs to trigger an interrupt, with another GPIO driven low during the interrupt handers.Manuel Del Basso said:What am I missing regarding breakpoint behavior in case of using a TI-RTOS setup?
Used CCS 7.1.0.00016 under Windows 7, and a Blackhawk USB2000 debug probe.
With the non-OS example when a breakpoint was set at the start of an interrupt handler with a skip-count of 5, the skip-count worked as expected. However, realized that with either a hardware or software breakpoint the skip count is handled by the debugger. This means that each time the breakpoint is hit the debugger has to increment the skip count and decide if to resume the target or leave the target halted. Therefore, use of a skip-count is intrusive on the target execution. A LSA watching the GPIO which was driven low during the interrupt handlers showed the act of using a skip-count caused the target to be halted for between 20 to 30 milliseconds before being resumed. Where the overhead to handle the skip-count will probably vary depending upon the type of debug probe and speed of the PC running the CCS debugger.
In the example I was using there are 32-bit integer variables which are incremented by the interrupt handlers on every call. Found that could setup a hardware watchpoint to trigger on the writes to the variables, and use a compare mode to trigger when the value was >=5. Since the variable is initialized to zero and incremented by one for every interrupt effectively gives a skip-count of 5 but such that the compare is handled by the target without intruding on the target's execution. An example for a hardware watchpoint set on the 32-bit Xint2Count variable incremented by an interrupt handler:
The LSA confirmed that the interrupt was run for 5 times at full speed, before the target was halted in the debugger when the Xint2Count variable got to the value of 5.
Would such a hardware watchpoint work-around your problem with the skip-count?
