breakpoint problems

Hi,

The issue can be related to several factors, including an unexpected reset on the DSP caused by other hardware components and even power supply issues.Are you able to run any code reliably on the board? Can you run your code in a DSK or EVM board without trouble? Also, are you able to halt the target if you don't set any breakpoints? 

If you can run the code in an EVM but not in your target board, then it could well be a hardware problem. Check any possible power supply failures or monitor the reset or clock pins to see if you can detect a spike that indicates the device is reset. I would also check the watchdog timer configuration (if enabled) to see if the DSP is not being reset unexpectedly.

If you can run and halt the target successfully without the breakpoint, then it may be located in a critical area of your code that is causing the hardware to fail. The address mentioned in the error message falls into the interrupt vector table - are you trying to set a breakpoint there? If so, keep in mind that halting a process in the middle of an ISR may cause a loss of data.

Unfortunately the custom hardware makes things a bit harder to debug, but I will get back if I have some additional ideas for things to check, ok?

Best regards,

Rafael

    Thanks a lot for your attention. I read your reply earnestly and ponder over my thing for long time.

     Unfortunately,I don’t have either a DSK or a EVM board.  Actually I run several reliable codes on my own board sucessfully. So, probably there is no problem with power supply. Also the watchdog timer is definitely shut down.

     In fact, I set a breakpoint in the middle of an ISR since I want to observe values of some variables. As you said ,halting a process in the middle of an ISR may cause a loss of data.  What should I do?

     I have had some puzzles about linker command files(*.cmd) for long time. I wrote two linker command files. Would you please check the two files for which I can’t be sure?

file 1:    

   MEMORY
{
  PAGE 0:
  VECS:    origin=0x0000,length=0x0040
  FLASH:   origin=0x0044,length=0x7fbc
 
  PAGE 1:
  SARAM_D: origin=0x0800,length=0x0800   

  RAM_EXT: origin=0x8000,length=0x8000
}

  SECTIONS
{
  vectors:  {} > VECS  PAGE 0     

  .text:    {} > FLASH PAGE 0
  .cinit:   {} > FLASH PAGE 0
  .switch:  {} > FLASH PAGE 0
  .bss:     {} > RAM_EXT  PAGE 1
  .stack:   {} > SARAM_D PAGE 1  
}

file 2:
   MEMORY
{
  PAGE 0:
  VECS:    origin=0x0000,length=0x0040
  FLASH:   origin=0x0044,length=0x7fbc
 
  PAGE 1:
  B0B1:    origin=0x0200,length=0x0200
  SARAM_D: origin=0x0800,length=0x0800  

}

  SECTIONS
{
  vectors:  {} > VECS  PAGE 0     

  .text:    {} > FLASH PAGE 0
  .cinit:   {} > FLASH PAGE 0
  .switch:  {} > FLASH PAGE 0
  .bss:     {} > B0B1  PAGE 1
  .stack:   {} > SARAM_D PAGE 1  
}

look forward to your reply!

Best regards

Libing Ma

Hi,

Setting a breakpoint in an ISR is perfectly legal, but I just recalled something: are you disabling interrupts when you enter your ISR code? Better still, are you setting the breakpoints after the interrupts are disabled?

I am not very familiar with the C2400 family, but interrupt nesting is usually a non-desirable condition: this nesting may never happen during normal execution, but if the processor is halted during the execution of an ISR, it gives time for the other peripherals to interrupt or queue its interrupt requests.

The linker command files seem ok to me - from what I see I can't think they are causing this. For additional linker command files, check the LF2407 examples code at:

http://focus.ti.com/docs/toolsw/folders/print/apslf240x.html

With regards to the error messages, the only thing I can imagine is that both CCSv2.1 and CCSv3.3 are showing very similar errors. This reinforces the idea the emulator is losing control of the device and CCS can't properly reset the device debug status (including any associated breakpoints).

Because CCSv2.x does not have a "disconnect" feature as CCSv3.3, the error message manifests itself when the software is shut down - the phase where CCS is also resetting the debug status.

Unfortunately I really can't pinpoint an exact reason to why this is happening, but I will let you know if I find something or have additional ideas, ok?

Regards,

Rafael

Hi,

I'm up against the same error: 

Trouble Removing Breakpoint with the Action "Terminate Program Execution" at 0x8196: Error 0x00000008/-1066 Error during: Break Point,  Cannot set/verify breakpoint at 0x00008196  

Target I'm using is F28035.

In an attempt to isolate the problem I minimized my program now looks like the following:

#include <DSP28x_Project.h> 

 int16 var1 = 0;
 int16 var2 = 0;
 int16 var3 = 0;


void main(void)
{
 InitSysCtrl(); 
                       
 while(1){}
 
}

The program as written crashes: pressing F5 ("Run") and after MAIUSC+F5 ("Halt")

note that the program stucks at highlighted line:

[...]

3FF8CC 761A        EDIS       

3FF8CD 6F00        SB         0,UNC

3FF8CE FFFF        ITRAP1     

3FF8CF FFFF        ITRAP1     

3FF8D0 FFFF        ITRAP1     

3FF8D1 FFFF        ITRAP1   

[...]

The strange thing that I do not understand is why if I comment out one or more

of the three statements "varX" the program works properly(!!), that is:

#include <DSP28x_Project.h> 

 int16 var1 = 0;
 int16 var2 = 0;
 //int16 var3 = 0; this declaration is commented!!!


void main(void)
{
 InitSysCtrl(); 
                       
 while(1){}
 
}

Can anyone suggest what I'm doing wrong?

Greetings to community.

Dave

Dave,

What is the exact version of CCS and compiler tools you are using? Could you also attach the complete build output from the CCS console window so we can see what options are being passed to the compiler and linker during the build process?

Hi, Aarti

Thanks for the reply. I enclose what you asked me.

• Version of CCS: Code Composer Studio Version 3.3.83.19

• Code Generations Tools: v5.2.1

• Build output:

---------------------------  Bug01_pjt.pjt - Debug  ---------------------------
[Bug01_c.c] "C:\CCStudio_v3.3MCU\C2000\cgtools\bin\cl2000" -g -i"C:/DM/Firmware/CCS3.3/Bug01/h" -d"LARGE_MODEL" -ml -v28 -@"Debug.lkf" "Bug01_c.c"

[DSP2803x_CodeStartBranch.asm] "C:\CCStudio_v3.3MCU\C2000\cgtools\bin\cl2000" -g -i"C:/DM/Firmware/CCS3.3/Bug01/h" -d"LARGE_MODEL" -ml -v28 -@"../Debug.lkf" "DSP2803x_CodeStartBranch.asm"

[DSP2803x_GlobalVariableDefs.c] "C:\CCStudio_v3.3MCU\C2000\cgtools\bin\cl2000" -g -i"C:/DM/Firmware/CCS3.3/Bug01/h" -d"LARGE_MODEL" -ml -v28 -@"../Debug.lkf" "DSP2803x_GlobalVariableDefs.c"

[DSP2803x_SysCtrl.c] "C:\CCStudio_v3.3MCU\C2000\cgtools\bin\cl2000" -g -i"C:/DM/Firmware/CCS3.3/Bug01/h" -d"LARGE_MODEL" -ml -v28 -@"../Debug.lkf" "DSP2803x_SysCtrl.c"

[DSP2803x_usDelay.asm] "C:\CCStudio_v3.3MCU\C2000\cgtools\bin\cl2000" -g -i"C:/DM/Firmware/CCS3.3/Bug01/h" -d"LARGE_MODEL" -ml -v28 -@"../Debug.lkf" "DSP2803x_usDelay.asm"

[Linking...] "C:\CCStudio_v3.3MCU\C2000\cgtools\bin\cl2000" -@"Debug.lkf"
<Linking>

Build Complete,
 0 Errors, 0 Warnings, 0 Remarks.

• Messages output:

Do you see this "Trouble Removing Breakpoint" error immediately after loading the code or when running the code? I assume you are running from Flash. If it is at runtime or when setting a breakpoint, it may be because you are running out of breakpoints. Try disabling the CIO and End of Program breakpoints: http://processors.wiki.ti.com/index.php/C2000_Flash_Common_Issues/FAQs#Using_Breakpoints_During_Debugging

Regarding the code crashing when some variables are commented/uncommented I was trying to see if there was some build options that might give a clue. I don't see anything in the compile options, but could you check in the Debug.lkf file if the linker is getting a -c (--rom_model) or -cr (--ram_model) option? In some cases, I have seen issues when neither option is specified, so make sure it is -c, and give it a try.

Hi Aarti,

I've never flashed F28035; I'm always running from RAM.

This is my Debug.lkf file:

-z -ecode_start -m"Bug01_map.map" -o"Bug01_out.out" -stack0x380 -w -i"C:/DM/Firmware/CCS3.3/Bug01/lib" -i"C:/CCStudio_v3.3MCU/C2000/xdais/lib" -i"C:/CCStudio_v3.3MCU/bios_5_33_05/packages/ti/bios/lib" -i"C:/CCStudio_v3.3MCU/bios_5_33_05/packages/ti/rtdx/lib/c2000" -i"C:/CCStudio_v3.3MCU/C2000/cgtools/lib"
"C:\DM\Firmware\CCS3.3\Bug01\cmd\28035_RAM_lnk.cmd"
"C:\DM\Firmware\CCS3.3\Bug01\cmd\DSP2803x_Headers_nonBIOS.cmd"
"C:\DM\Firmware\CCS3.3\Bug01\Bug01_c.obj"
"C:\DM\Firmware\CCS3.3\Bug01\c\DSP2803x_CodeStartBranch.obj"
"C:\DM\Firmware\CCS3.3\Bug01\c\DSP2803x_GlobalVariableDefs.obj"
"C:\DM\Firmware\CCS3.3\Bug01\c\DSP2803x_SysCtrl.obj"
"C:\DM\Firmware\CCS3.3\Bug01\c\DSP2803x_usDelay.obj"
"C:\DM\Firmware\CCS3.3\Bug01\lib\rts2800_ml.lib"

It seems that the linker does not receive any of the two (-c) or (-cr) options, but I solved the problem!!

Following your advice I tried to change some build options and I found the culprit:

• Compiler > Basic > Opt level =  None  BAD
• Compiler > Basic > Opt level =  File (-o3)  WORKS GOOD
  

Dear Community,

I thought I had solved the problem but I was deluding himself...the reality is that solution

proposed by me:

[...]

Following your advice I tried to change some build options and I found the culprit:

• Compiler > Basic > Opt level =  None  BAD
• Compiler > Basic > Opt level =  File (-o3)  WORKS GOOD

Dear Community, Dear Aarti,

Perhaps I finally managed to solve this annoying error using the following settings:

• Compiler > Basic > Opt level =  None 
• Linker>Basic>Autoinit Model: Run-Time Autoinitialization (-c)