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/RM42L432: Debug problem(about interrupt and self_test)

Part Number: RM42L432
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

P/N: RM42L432 .

IDE: CCS 5.5.0 .( complier version :5.1.14)

     HALCoGen 04.05.01

Debug tool: XDS100V2 USB Emulator

 I found it can't work and stop at init_00 when i use ccs debug ,[i only want to monitor the variable].

whether the reason is as the following figure describe?( self _test prevent debug mode?)

2. I use two methords to enter debug mode

   2.1      a-- connect JTAG to the  PCB board

              b-- suspend

             c-- power off -on   the PCB board

             d--connect to the target

             f-- i can monitor the variables,

  2.2    choose debug mode --load symbols only.

         i find this way can also enter into debug mode  successfully.

3.   but  the most serious problem is " the interrupt can't work" 

     3.1  i use SPI、SCI、A/D、RTI、QEP.

               for example ,in 1ms task ,i will generate a signal to drive a LED every 100 ms. but the LED never on.

  4、 this is the basic information about my project .

          Can you tell me the direction of problem solving ?

          Any conflict between self_test and debug mode ?

    tks very much !

  • Hello John,

    What I suspect is happening in your case with STC enabled is that any watched variables or breakpoints setup to monitor interrupt execution are being lost as a result of a CPU reset. The STC execution will cause a CPU reset after completion of each interval. Since the debug information is stored within the CPU, it is lost whenever there is a CPU reset. This means that if you have breakpoints or watched variables showing in CCS, they will no longer be active on the device.

    One method of working around this issue is to store off the debug registers as a context save prior to initiating the STC execution (see Cortex-R4 TRM on ARM website for more information on debug registers and other CPU registers). Once STC is complete, you will then need to restore the debug register contents by moving the saved context back into the CPU registers.

    This task of doing the context save and restore is really only relavent in 2 scenarios. First, if you are running STC during a live application and not simply at start up, then it has to be done so that the application can continue and no information is lost. The second scenario is if you are trying to debug as you have described and you want to use breakpoints from boot time where the STC is ran during boot. The latter reason would only affect debug but would be a carry over into your application using unecessry RAM resources and processing time. As such, TI recommends disabling the STC execution during debug and/or doing boot time profiling outside of the debugger.
  • Chuck Davenport

    Thanks for your support