• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 411 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320C5515: Trouble Removing Breakpoint with the Action "Finish Auto Run" at 0x3498c: (Error -1066 @ 0x3498C) Unable to set/clear requested breakpoint....

citizen
Expert 2780 points
Part Number: TMS320C5515

Hi,

I've recently imported / ported some code used on a CCS3.3 platform that used to compile and run well on the CCS3.3 platform etc.

I'm now compiling and using CCS12 and am getting the following error when halting the program run : 

Trouble Removing Breakpoint with the Action "Finish Auto Run" at 0x3498c: (Error -1066 @ 0x3498C) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory...

Moreover the following window pops-up : 

I am not entirely sure why I'm getting these errors but this doesn't seem normal and I would like to ask for suggestion for why these errors occur please ?

Cheers, Mike

  • 0
    TI__Mastermind 45445 points

    Hi Mike,

    Which CSL version are you using? As I recall, there are some major changes when we move from CCS 3.3 to CCS 6.0. The CSL 03.08.00 is using the CCS 6.0. When you use CCS12, you will need to download and install the CGT for C55xx 4.3.9 from the following URL: Code Generation Tools for Texas Instruments Processors : Downloads.

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Expert 2780 points

    Hi, yes thanks for the heads-up. I am using CSL 3.08.01 which is the latest for the C55xx devices from what I know... The latest CGT is V4.4.1 which we are using.

    The problem is that I do not think this is the issue CSL and CGT are pretty much the latest, and besides, at the start I was not getting these errors ... Something more recent, like some path some where that got screwed up and now there are some files not correctly loaded ... otherwise I do not see why I should have to "set the source lookup path" to find some files for the debugger when the project path is well defined etc...

    I'm sure there is a some simple solution to this...

    Regards, M

  • 0 in reply to citizen
    TI__Mastermind 45445 points

    Hi Mike,

    The knl_run.c is not part of the CSL. I am thinking your application code may use the DSP/BIOS API. If that is the case, then the issue may be caused by the DSP BIOS versions. Make sure you are using the DSP/BIOS 5.42.00.07 and DSP/BIOS 5.42.02.10.

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Expert 2780 points

    Hi Ming,

    Yes I am using DSP/BIOS 5.42.02.10 and yes the knl_run.c is not part of the CSL as you say, so there's some other setting/path that seems to be an issue. This seems also to be mainly an issue when debugging etc. 

  • 0 in reply to citizen
    TI__Mastermind 45445 points

    Hi Mike,

    I confirmed that the KNL_run() in knl_run.c is part of DSP/BIOS. If the DSP/BIOS version is correct, then the other possible cause may be the stack size. Can you increase the stack size for the system stack?

    Best regards,

    Ming 

  • 0 in reply to Ming Wei
    Expert 2780 points

    Hi there Ming,

    So after some further tweeking, and redoing the porting of the legacy 3.3 project to the CCS12 platform, it seems OK now. Mind you there is a bit of fidling around with the emulator settings. It seems to be very sensitive to boards with the EMIF active (with external SDRAM), and I did believe I may have had a particular Debug setting "Reset the target on a program load or restart" which may have caused some trouble, since the EMIF and external SDRAM may not have been fully "ready" for CCS to load the code correctly. I noticed this when I switched over to "Full Verification" in the code verification options, in that my code was not loading properly and on launch it was then going straight to lala land !

    In any case it seems to be OK for now and I can execute and step through the code as before on the legacy platform etc. Thanks for you suggestions, much appreciated ;-)

    cheers, Mike

  • 0 in reply to citizen
    TI__Mastermind 45445 points

    Hi Mike,

    I am glad it finally works for you.

    As of the JTAG settings for stable running, I found the TCLK frequency for the JTAG is critical. You may want to reduce the JTAG TCLK Frequency, if the JTAG is not very stable. See the attached screen shot for details:

    Best regards,

    Ming