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.

I find it not easy to debug TiVa :(

Hi all,

I find it a headache to debug TiVa project (I use 1294 LaunchPad). Maybe I missed something, so I will appreciate any pointer from anyone, thanks!

1)I have trouble turning on breakpoint to the codes, A lot of times, when I try to turn on a breakpoint, I only get a check mark with a "\" across, indicating I can't use it

2)There are sections of codes I can't add break point at all (Maybe I can't use breakpoint in ISR or callback?)

3)When I step through the codes, the program pointer goes into lines that have no codes or it doesn't follow a simple program flow

I run int FaultISR once a while, and due to the above 3 issues, I usually end up reverting back to a backup of my project and start over again without truly understand what causedFaultISR. ps. What is the most common mistakes that cause FaultISR?

Again, I will appreciate any pointer, thanks!

  • Hi David,

    First of all, do check the thread "Diagnosing Common Development Problems and Tips for TM4C Devices" on the forum front page - there's a section about FaultISR's as well - and a link to a document describing how to debug them. It's not a task for the faint hearted, but very much achievable by mere mortals as well!

    My attempts at answers to your questions - the only guarantee I can give is that this list is incomplete:

    1) Check that you don't have "Skip all breakpoints" enabled. When in the debug view, check the "Run" menu - you should see the option there. (I assume you use CCS)

    2) Do you mean certain lines or entire sections? For lines, do note that not all lines actually translate into CPU instructions, thus a breakpoint can't be added. From my experience if you do this, CCS will automatically move the breakpoint to the next applicable line. For entire sections, ensure that you don't have any #ifdefs or the like that actually keep that part of the code from compiling.

    3) Possible reasons include: an overflown stack, code compiled with optimizations on, mismatching versions of source code & binary

    Regards,
    Veikko
  • 1 & 2 & 3) Which IDE/Compiler are you using? In general when you have trouble setting breakpoints in a particular line, it's due to the compiler optimization settings(besides number of breakpoints limit). Switch to the lowest level or no optimization, if you can(code size will go up).

      

    Regarding the FaultISR, most likely a peripheral not turned on(clock), or wrong settings. You can find out(in general) which one is causing the trouble by looking at the Bus Fault Address.

  • Beyond the (very) sound advice both responders have provided - resist the temptation to, "Create your own project!"

    So often - when tried - vital "linkages" are broken/missed/disrupted - and while your IDE may "appear" to accept your "personalization" - critical portions (way too frequently) hiccup!

  • Hello David,

    When a library is compiled and/or the code has optimization set, CCS exhibits this behavior of skipping lines or showing code that is not getting executed. Switching off optimization and compiling the driverlib gets them out (at the expense of code size)

    Regards
    Amit
  • May I add that (glorious) IAR & Keil (both "pro" IDEs - able to harness ALL vendors' ARM MCUs) suffer the same limitations when optimizations are set (which unfortunately {usually} is their default behavior!

    *** May I register "dispute" over the award of Verify to the (last) responder.   Both earlier posters identified the issue (not moi) - and are deprived of their rightful AWARD - likely due to their lack of "vendor portfolio!"    Unfair & improper...   

    Note now that one of those "instant" responders has been rewarded...

  • Sorry, I was not familiar with the scoring system

    Since my post actually contains multiple questions, I thought both were answers to some of the questions.

    Totally my fault. I only wish I could transfer points to them as compensation
  • David,

    No one wants your sorrow - you asked a reasonable question rather well - but rewarded "paid help" while "volunteers" went hungry!    And those volunteers responded faster - and with precision - earned their Verify!
     
    You've corrected for poster Veikko - if you add same method to Marc_rir that "award loop" should be closed.

    While I'm not award-worthy - do consider avoiding, "Create your own."     Most such creations lead to, "NOT Good for Gov't Work!"      (and for what?)

  • Amit takes it all, the looser has to fall :)

    I don't really care about the scoring, but rather about the solution, what was it now, only the optimisation or in combination with the driver lib?

    Also what about the FaultISR? It's always nice to have, not only a 'Verify', but also a feedback to your 'particular' solution of the problem, cause this can help us too in the future.
  • (Loser) has to fall. (if you say so)     This is not, "Zero sum game" multiple verifies are possible.   (Veikko got one)

    Broad questions lead to the uncertainty you note - poster guidelines (some here have so lobbied) have best chance to correct...

  • Amit's suggestion regarding lib solved the problem of random walk when stepping through, the others makes it breakable, #ifdefs was never the problem

    I haven't got another FaultISR yet, I recall that I sometime can make it go away by cycling the power on the launchpad

    [Added] Almost forgot it: "skip all break points" was accidentally turn on to create the breakpoint with slash symbol.

  • I've should have said; 'the loser standing small' form the ABBA song 'the winner takes it all' :) It was just a joke...

    But as you said, Veikko also replied with multiple (valuable)possibilities, so when TO just pushes the 'Verify' button, we still don't really know what the solution was.