• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 378 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.

TM4C1290NCPDT: Firmware generated reset

Priya Nadathur70
Expert 2795 points
Part Number: TM4C1290NCPDT

SysCtlResetCauseGet returns a 1. I need to find what is causing this reset.

Probing HW watchdog GPIO and MCU reset pin is not generating a trigger on the scope

when the reset happens. I am re-running this again to confirm.

I have a HW watchpoint set at NVIC_APINT register. The execution did not halt here either

the first time I ran it. Not sure what else to do to track the cause of this reset? What tools can

I be using?

Thanks,

Priya

  • 0
    TI__Guru**** 191886 points

    Hi,

      If you read a 1 then it is a External reset. Please see below. You want to use a scope to capture the nRST input. 

    If you have an unexpected external reset, please see if you board has followed the below recommendations. Ex. if you have proper pull up resistor on the nRST pin. Also check if you have a stable power supply on the VDD. Your voltage regulator might have tripped if the VDD is out of range. You can also refer to the TM4C129 system design guidelines app note for details. http://www.ti.com/lit/an/spma056/spma056.pdf

  • 0 in reply to Charles Tsai
    Expert 2795 points

    Thank you for the information from the datasheet. 

    The driverlib API however says this:

    26.2.2.47 SysCtlResetCauseGet
    Gets the reason for a reset. Prototype: uint32_t SysCtlResetCauseGet(void)
    Description: This function returns the reason(s) for a reset. Because the reset reasons are sticky until either cleared by software or a power-on reset, multiple reset reasons may be returned if multiple resets have occurred. The reset reason is a logical OR of SYSCTL_CAUSE_HSRVREQ, SYSCTL_CAUSE_HIB, SYSCTL_CAUSE_WDOG1, SYSCTL_CAUSE_SW, SYSCTL_CAUSE_WDOG0, SYSCTL_CAUSE_BOR, SYSCTL_CAUSE_POR, and/or SYSCTL_CAUSE_EXT.
    Returns: Returns the reason(s) for a reset.

    This seems to indicate there might be multiple causes for a reset. Is this true?

  • 0 in reply to Priya Nadathur70
    TI__Guru**** 191886 points

    Hi Priya,

      Yes, it is possible that multiple flags can be set at the same time. Per your original question, you said calling SysCtlResetCauseGet() returns 1. This means only the EXT flag was set. This is a nRST. This is the reason I suggested you to scope capture the nRST and the power supply. The nRST is normally controlled by your voltage regulator. If the nRST is pulled low, the voltage regulator might have detected an voltage out of range. 

  • 0 in reply to Charles Tsai
    Expert 2795 points

    Yes, I am using a scope to trigger on the reset line. The scope reliably triggered twice so far. 

    Reason why it didn't trigger 4-5 times before this is unknown. Trigger signals and levels on the

    scope has been checked many times.

    If there are two causes of reset, will the logical OR be 2? It will help if the driverlib API and datasheet

    offer same clarity.

    Thank you,

    Priya

  • 0 in reply to Charles Tsai
    Guru 117855 points

    Greetings Charles,

    My group found your initial response perfect.    (EXT generated the reset.)

    Might poster's issue revolve around the (strict) interpretation of the language, "Multiple flags can be set at the same time?"     My group's belief is that "Multiple flags may 'appear' - when the RESC Register is read."     This does not imply that, 'All such flags were 'set' at the same time!     Instead - they most likely were set individually/sequentially.     

    Note that these flags are described as being 'sticky' (i.e. will persist until cleared.)     Confusion as to 'which flag caused the Reset' may be eliminated (surely reduced) by regular 'test' of RESC - and clear - of the register bit as soon as it is noted.    (That 'test' can automatically follow each/every MCU Reset - simplifying the process.    It is (only) when 'multiple Resets are allowed to accumulate' (w/in RESC) - that confusion as to the 'Last Reset's Source' - may arise...)

  • 0 in reply to cb1_mobile
    TI__Guru**** 191886 points

    Hi cb1,

      Thank you. You are perfectly correct. I should have said multiple flags can appear to set when the register is read instead of the flags can be set at the same time. However, in another MCU device that I work with, it is indeed that multiple reset flags can be set in the same cycle. 

  • 0 in reply to Charles Tsai
    Guru 117855 points

    Charles Tsai said:
    However, in another MCU device that I work with, it is indeed that multiple reset flags can be set in the same cycle. 

    Indeed Charles - as my small Tech Firm employs (primarily) ARM Cortex MCUs from (now) FIVE Vendors - we too, 'Bump against 'different behaviors' which force 'high focus & readiness' upon us.'

    As a general statement and/or observation - we don't find that 'too often' - multiple causes of Reset occur (near) simultaneously.    (unless an event of GREAT Significance has occurred - and then FULL ATTENTION is demanded...)