• State Resolved
  • Locked Locked
  • Replies 19 replies
  • Subscribers 32 subscribers
  • Views 2983 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.

Launchpad´s strange FaultISR

jozo jozic
Prodigy 80 points


Hello!

I`m using Tiva TM4C123 Launchpad to control another device via SPI. I can´t use CCS Debugger because in that case the program gets stuck in the beggining (a Sleep loop that uses: while (_clock() - t0  < dt); waiting scheme), I just load the program and I debug with printf´s.

I´m experiencing strange issues (appearing on multiple locations in the code). I´ll name one example.

In this example, the code won´t work unless I define a variable (which I don´t need & use). Here is a screen of a working version (with the declared variable, tmp):

This works ok. Now, if I comment the variable tmp, the code gets stuck in another part, it doesn´t even reach this part, it goes to FaultISR.

I discovered this by turning on the LED when I reach FaultISR (in startup_ccs.c).

I also print the NVIC_FAULT_STAT_R register, which contains 20000 value, which corresponds to NVIC_FAULT_STAT_INVSTAT - Invalid State Usage Fault. This might mean that Branch command has LSB 0 (it should be 1, Thumb instructions). But I also see in the working code that some Branch instructions have LSB 1, some LSB 0 (am I reading that correctly?! ).

Why is NOT defining a useless variable causing the Fault? How can I fix this?

If anyone can suggest anything that might point to solution, please help! I´ll try to do something to have the Debugger useful, but for the time being I can´t use it.

Thank you in advance!

  • 0
    Guru 92251 points

    jozo jozic said:
    Why is NOT defining a useless variable causing the Fault? How can I fix this?

    Without the full project it is difficult to give an exact reason.

    A guess at some possible reasons:

    a) The program has a bug which is overwriting something on the stack, and the useless variable changes where in memory other variables are which hides the bug.

    b) There is insufficient stack space. Does increasing the stack space make the bug go away?

  • 0
    Guru 47900 points

    jozo jozic said:
    I can´t use CCS Debugger because in that case the program gets stuck in the beggining

    Might turning your attention "there" (getting stuck in the beginning) make more sense than resorting to printf - to debug?

    Ten to one you've, "Created your own program" (always w/out the report of justification) which has destroyed necessary IDE linkages - and most likely caused your plight.

    Would it not make good sense to instead, "Load a simple/short factory supplied program" (NOT one of your own creation) and "practice the debug and other IDE operations - in that manner?"    Again - resist all temptation to, "create your own" use only those programs & IDE settings as supplied by the vendor.

    Once that's done - and proper debug capability returns - you may, "Slowly, gradually, methodically add in lines of your custom program" and proceed with a far greater chance of success...

  • 0 in reply to Chester Gillon
    Prodigy 80 points

    b) Well, when I increase it, it goes into FaultISR again, but it doesn´t print the NVIC_FAULT_STAT_R register :/ yeah, something is very wrong with this code :(

    But can it be that compiler does something wrong, that he sometimes produces the wrong Branch instruction? Or something else in a wrong way?

    Should I upload the project? (although you can´t reproduce the error because you need the other device with which I´m communicating)

  • 0 in reply to cb1
    Prodigy 80 points
    I've used blinky or uart example, I didn't start from scratch...
    I was modifying this program to work on my Launchpad (it was written for an STM MCU). There was the fully portable part, and the device-specific part. I rewrote the device-specific part, tested that it works, and then tried to merge it.
    The absence of debugger use didn't seem that normal, but since the program execution got stuck in the portable part, and I wanted to change it as least as possible, I figured it worked on the STM one, so I turned to printf's. (Offtopic, from some previous stuff I did, I've noticed on some small details that the Launchpad sometimes works a bit differently (better) without the debugger, like in this example. But I guess I will have to change a lot of things in this code)
  • 0 in reply to Chester Gillon
    Prodigy 80 points

    But I don't think that it's the stack, I've tried printing it and it was somewhere in between top and end. Also, I've checked .map file, there is still plenty of SRAM and Flash memory left (it's not like the program is too big). Anyway, I guess I have to get the debugger running somehow, rewrite some code, then it should more clear.

  • 0 in reply to jozo jozic
    Guru 11940 points

    I've used blinky or uart example, I didn't start from scratch...

    I'd like to second the opinion of Chester Gillon. Those are small examples, and don't have much impact on the stack. As soon as you do something "real", you need to think about the stack size (and resource usage in general). Especially printf - like functions have hidden, but often tremendous impact on stack usage.

    I've noticed on some small details that the Launchpad sometimes works a bit differently (better) without the debugger, like in this example.

    Debuggers are more or less intrusive.They need some resources, too. And worse, they may implicitly clear interrupt flags before your code reads them, thus altering the code path.

  • 0 in reply to f. m.
    Prodigy 80 points
    It was the stack! Besides changing it under Properties->Build->Linker->Basic Options, I had to change it in .cmd file, and then it worked! Thanks a lot!
  • 0 in reply to jozo jozic
    TI__Guru**** 244400 points
    Hello Jozo,

    While increasing the stack helped, did you check if the function call is not iterative that may cause problems later?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 80 points

    Amit Ashara said:
     
    While increasing the stack helped, did you check if the function call is not iterative that may cause problems later? 

    Hi Amit, sorry, but I don't get it :/ what function call?

  • 0 in reply to jozo jozic
    Guru 11940 points

    I guess Amit really meant "recursive" function calls, i.e. a function that calls itself. Recursion is not a strength of the C language, so better avoid it.

    If you look for an example of recursion, add the search term "fibonacci". The algorithm to evaluate a number of the fibonacci sequence is best suited for a recursive implementation (in an appropriate language...).

  • 0 in reply to f. m.
    Prodigy 80 points
    I thought it was related to this issue, that's way I didn't understand well, because here the issue was about the variable... but yeah, on some other locations in program it got stuck just before some functions...that was due to the small stack.
    I didn't use recursion.
  • 0 in reply to jozo jozic
    TI__Guru**** 244400 points
    Hello Jozo,

    You may not have used recursion, but the function call may be recursive. What I am trying to arrive at is the fact that during testing for extended hours does the application remain stable?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 80 points

    Amit Ashara said:
     
     You may not have used recursion, but the function call may be recursive. What I am trying to arrive at is the fact that during testing for extended hours does the application remain stable?
     

    I didn't test it for hours yet, but the shorter tests were all fine. Sry for tuoring demand, but how can a function call be recursive if I'm not calling the function from the function itself? :D

  • 0 in reply to jozo jozic
    TI__Guru**** 244400 points
    Hello Jozo,

    Not necessary for a function to call itself, but consider the case func1 calls func2 calls func3 and an interrupt strikes. Remeber they all are PUSH and POP into the stack.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 92251 points

    Amit Ashara said:
    Not necessary for a function to call itself, but consider the case func1 calls func2 calls func3 and an interrupt strikes.

    Finding out static stack usage describes how the call_graph utility can be used to statically determine the worst case stack usage for the possible calls which may occur.

    By adding the reported worst case stack usage for the main program and the interrupts you can determine the stack size requirement.

  • 0 in reply to Chester Gillon
    TI__Guru**** 244400 points
    Hello Chester

    Did you mean Software Profiling?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27665 points
    I have used semi-automatic utilities to do this before. Some compilers will report this as well. It is BTW not recursion and will break in the presence of either implicit or explicit recursion since there is no good way to determine the stop point w/o value track. PC-Lint will also report this as well and it can be used in the presence of limited recursion (by predefining call depth). None of these options actually require the code to run.

    What you referred to as recursion is actually re-entrancy. Common in multi-threaded environments and interrupts.

    Robert
  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello Robert,

    Yes, I meant re-entrant. Big time apologies for the confusion of the correct technical word.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27665 points
    We all do it Amit, especially when the concepts are similar.

    Robert