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

Tiva SW Reset - What caused?

Bruno Saraiva
Guru 13040 points

I have a TM4C1294 which is software-reseting.

Early in the code I check the cause and clear the register:

resetCause = SysCtlResetCauseGet();
SysCtlResetCauseClear(0x107F); // Clear all known reset causes

And the cause is SYSCTL_CAUSE_SW.

Is there any strategy to find out where was the code running when the reset happened? I'm having a hard time to step into debugging on this particular case...

The issue causing the reset seems to be similar to what was posted on the thread below - but still, I'd like to figure out if the "last living location" can be figured out.

e2e.ti.com/.../531446

  • 0
    TI__Guru**** 244400 points
    Hello Bruno

    Software reset is asserted by the software core or by using the debugger when a system reset is issued. If you are using the debugger then it is obvious why the bit will get set.
  • 0 in reply to Amit Ashara
    Guru 13040 points
    Hi Amit,

    Not sure I understood...
    Does that mean that, when the debugger is attached and running, any other reset cause will sill be seen as a software reset?

    If not, let me add some explanation: the board is continuously resetting itself: it starts, runs to "somewhere in the code", and goes back to the start again - it shouldn't. Expected behavior is that it starts, runs all the one-time commands before a while(1) loop, enters the while loop and remains there forever.
  • 0 in reply to Bruno Saraiva
    Guru 27665 points

    Bruno Saraiva said:
    Not sure I understood...
    Does that mean that, when the debugger is attached and running, any other reset cause will sill be seen as a software reset?

    It means when a reset is issued over the JTAG it is seen as a SW reset. I see this when I download new software.

    Trace is effective at finding problems like this, otherwise it is pretty much a hunt and peck process.

    Robert

  • 0 in reply to Bruno Saraiva
    Guru 27665 points
    If you have a known good version then you should probably revert and add changes back slowly. The only other general approach is progress markers (set an output or a value in memory based on what the last successful execution point was).

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points

    I would ask if the Watchdog was active & enabled? (that's not been admitted)

    Also - while firm/I avoid 129 we find "Power Supply Sensitivity" to cause similar upon (past) LX4F and (rarely) upon our (faster & more capable) M4s & M7s. In any such troubleshooting exercise - guaranteed stable and "to spec" power delivery is mandatory. (Krazy making occurs, otherwise...)

  • 0 in reply to Bruno Saraiva
    TI__Guru**** 244400 points
    Hello Bruno,

    No. When you restart a program using a System Reset, that is when a software reset occurs if the application itself does not invoke it.

    Connect the debugger and put a hardware watchpoint on the NVIC's APINT register access. This register is defined at 0xE000ED0C. An access by the software should stop the code execution.
  • 0 in reply to Amit Ashara
    Guru 13040 points
    Alright Amit, the suggestion of putting the watchpoint on a register is what the post title was looking for!

    For what is worth, I did find the culprit yesterday by "advancing step by step..." One quite interesting point is that the problem I had was EXACTLY the same as described by Craig on the thread I linked on the first message: it was a weird reset behaviour when the serial Tx buffer was filled up.

    In the end, the reset itself was proven to be a legitimate command, and programmed in a totally separate part of the code - but the debugging sequence misguided the user to think it was something about serial transfer, interrutps or buffer invalid addressing... And to make my line of though harder, I had received this particular board with a whole bunch of 4700pF capacitores on all of the places where the project expected 0.1uF, so I was biased to expect some sort of bad power supply reset...

    Thanks for all the input.
  • 0 in reply to Bruno Saraiva
    Guru 27665 points

    Bruno Saraiva said:
    I had received this particular board with a whole bunch of 4700pF capacitores on all of the places where the project expected 0.1uF, so I was biased to expect some sort of bad power supply reset

    That must have resulted in some blue air.

    Bruno Saraiva said:
    In the end, the reset itself was proven to be a legitimate command, and programmed in a totally separate part of the code

    Consider supplementing the built-in reset cause register by adding a variable to indicate the place the reset command came from in the case of a software commanded reset. Saves you from a lot of stress.

    Robert

  • 0 in reply to Bruno Saraiva
    TI__Guru**** 244400 points
    Hello Bruno

    But did the watchpoint trigger?
  • 0 in reply to Amit Ashara
    Guru 13040 points
    Amit,
    I did not actually try. I saw the message about register watchpoint this morning, after I had figured the problem the hard way yesterday.
    Still a tight schedule this week, I made a note to test this concept later, and I will post back.
    Robert,
    "...adding a variable to indicate the place the reset command came from..." - is that something doable AFTER the reset/boot?
  • 0 in reply to Bruno Saraiva
    Guru 27665 points

    Yes, there are a couple of methods Bruno

    • Use EE, Timing is an issue here and more importantly the TM4C errata
    • Reserve an area of memory so that it is not initialized by the C runtime. The procedure varies somewhat by toolset (the most universal way is to create a new section that is not part of the initialised C memory section using the assembler) but it's usually reasonably straightforward. You would need to init it in the case of a power on reset but otherwise it will just keep the last value written to it as long as there is not a power reset. I suspect you toolset has a pragma that would do that for you, not portable but....

    Robert