• Locked Locked
  • Replies 1 reply
  • Subscribers 54 subscribers
  • Views 1101 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMDSPREX28335: Breakpoint overrun / Breakpoint "skip-count" stops counting when running TI-RTOS setup

Manuel Del Basso
Prodigy 10 points

Part Number: TMDSPREX28335
Other Parts Discussed in Thread: TMS320F28335, CONTROLSUITE

Tool/software: Code Composer Studio

Hello ti community,
I'm using CCS7 + F28335 explorer kit to train me into C2000 Family, since several weeks I deal with TI-RTOS/ROV/RTOS-Analyzer. In addition to numerous positive experiences, the breakpoint behavior is a big problem. Apart from some annoyingly workarounds I'm not able to overcome the "skip-count" problem.
1.) Breakpoint overruns 
  • ePWM1 module configured for 20kHz PWM, output on GPIO0
  • XINT1 configured to be sourced on GPIO1s falling edge, GPIO0 and GPIO1 are shorted
  • The IRQ handler of XINT1 toggles GPIO2 two times between some NOP's

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")
main.c, line 115 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5 (0) Remain Halted 
Case A (non-RTOS setup): 
After the Restart+Resume sequence, the debug session enters Remain Halted, the breakpoint view updates as expected:
main.c, line 115 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5 (5) Remain Halted 
Case B (RTOS setup): 
After the Restart+Resume sequence, the debug session never enters Remain Halted and when I hit Suspend, the breakpoint view updates to
main_rtos.c, line 120 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5 (1) Remain Halted 
In both cases, the ePWM signal could be validated via Oscilloscope so I'm quite sure that my simple RTOS setup should behave like the non-RTOS setup?! 

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:  

- Restart: (Stops at main entry point)
    + main_rtos.c, line 120 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5 (0) Remain Halted 
    + main_rtos.c, line 125 (C$L6) [H/W BP] Breakpoint 0 (0) Remain Halted
- Resume:
    + Break on line 120
    + main_rtos.c, line 120 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5 (1) Remain Halted 
    + main_rtos.c, line 125 (C$L6) [H/W BP] Breakpoint 0 (0) Remain Halted
- Resume:
    + Break on line 125
    + main_rtos.c, line 120 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5 (1) Remain Halted 
    + main_rtos.c, line 125 (C$L6) [H/W BP] Breakpoint 0 (0) Remain Halted
- Resume:
    + Break on line 125
    + main_rtos.c, line 120 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5  (1)  Remain Halted 
    + main_rtos.c, line 125 (C$L6) [H/W BP] Breakpoint 0 (0) Remain Halted
- Resume:
    + Break on line 125
    + main_rtos.c, line 120 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5  (1)  Remain Halted 
    + main_rtos.c, line 125 (C$L6) [H/W BP] Breakpoint 0 (0) Remain Halted

(...inf Resumes...)

The only thing I can do to "Re-Arm" the breakpoint on line 120 is a disable/enable sequence:    

- Resume:
    + Break on line 125
    + main_rtos.c, line 120 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5  (1)  Remain Halted 
    + main_rtos.c, line 125 (C$L6) [H/W BP] Breakpoint 0 (0) Remain Halted
    + disable BP on line 120
    + enable BP on line 120
- Resume:
    + Break on line 125
    + main_rtos.c, line 120 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5  (2)  Remain Halted 
    + main_rtos.c, line 125 (C$L6) [H/W BP] Breakpoint 0 (0) Remain Halted
- Resume:
    + Break on line 125
    + main_rtos.c, line 120 (XINT1_isr + 0x9) [S/W BP] Breakpoint 5  (2)  Remain Halted 
    + main_rtos.c, line 125 (C$L6) [H/W BP] Breakpoint 0 (0) Remain Halted
(... must be Re-Armed again...)

What am I missing regarding breakpoint behavior in case of using a TI-RTOS setup? 

Best regards,

Manuel

----

 - Hardware
     - TI TMS320F28335 Explorer Kit for TI C2000™ F28x 
 - Software
     - Code Composer Studio Version: 7.1.0.00016 (CCS7)
     - Board support via ti's controlSUITE v3.4.5 (www.ti.com/.../controlsuite
     - SYS/BIOS 
         + Version: 6.33.4.39
     - TI-RTOS for C2000
         + Version: 2.16.1.14 or
         + Version: 2.12.1.33
 - Development Plattform
     - lsb_release -d: Linux Mint 18 Sarah (LinuxMint)
     - uname -rpo: 4.4.0-57-generic x86_64 GNU/Linux
  • Guru 92251 points

    Manuel Del Basso said:
    What am I missing regarding breakpoint behavior in case of using a TI-RTOS setup? 

    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.

    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?