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.

Reset Cause register



Hi all,

On a TM4C129 processor ("Snowflake"), I'm trying to use the TivaWare function SysCtlResetCauseGet to find out the reason a processor is resetting. I inserted some test code after bootup that calls that function, and I've confirmed via debugger that the result I'm getting is always "0".

This seems strange to me since that's not a listed value. Even when I cause a reset via some known method, I see this function return 0.

I've also checked the underlying register, and that register is also 0. 

To the best of my knowledge I am not clearing this value. However I am starting TI-RTOS before I query the value.

Is there some setup step I'm missing, or some prerequisite? I couldn't find one in the documentation or the errata.

Thanks,

Ben

  • Have you tried reading using SysCtlResetCauseGet before starting TI-RTOS and (if necessary) tucking the value away in your own variable to read at your leisure later?

    It doesn't seem highly probable that TI-RTOS is clearing the value but it's possible.  I know the call works on a different processor.  I've already started all the peripherals I need by the time I read the reset cause register.

    That won't immediately answer your question but it might eliminate some suspects or strongly suggest a culprit.  The sooner you can read the register the smaller the list of possible interfering procedures.

     

    Robert

  • Hello Benjamin

    I agree with Robert on the fact that this is being cleared by RTOS. If you erase the flash and then do a power cycle of the board, the RESC register in System Control will show POR as the reset cause. The ROM does not touch this register and neither does your code. So the only code that can clear the register is the RTOS.

    Regards

    Amit

  • Thank you all for your assistance. As you (and I) suspected, it is the RTOS code that's clearing that register on startup. Moving the code to before RTOS and storing it in a global variable which survives RTOS initialization, I'm able to see the value.

    I don't suppose anyone from TI could answer why this register is cleared on RTOS init? This seems like exactly the opposite of what a reasonable implementer would want to occur, and further I couldn't find any information in the RTOS/BIOS user's guide indicating that this is expected/desired behavior. I think this may be a bug.

  • Hello Benjami

    or it may be saved in a variable/structure that can be accessed by the Application!!!

    Regards

    Amit

  • Agreed Benjamin,

    Unless the RTOS performs a documented action based on the source of the reset it should not be clearing the reset cause register and maybe not even then.  The application may have good reason not to clear the register.

    If the RTOS is not performing any action based on the reset source (reading the cause and storing it somewhere else certainly doesn't count2 and seems at best a waste) then it has no business clearing that register.  It can only be a source of bugs1 and as such I would consider it a bug myself.

    Robert

    1 - Since it does not have a useful purpose, then at best it has no effect.  Since any code is potentially a bug source the only real effect of code that does nothing is to introduce a source of bugs.

    2 - Especially if it is undocumented.

  • Hi all,

    I wanted to check with the folks from TI and see if you're considering this a bug, and if not, why not? I haven't seen any TI person respond here with something that makes me think you're taking action.

    Thanks,

    Ben

  • Hello Benjamin,

    From a device perspective we know that the RESC correctly reflects the reset status. I think this question needs to be posted in TI-RTOS forum to find out whether this is a bug or is it a documented feature.

    Regards

    Amit