• State Answer Suggested
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1882 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.

EK-TM4C1294NCPDTI3-XL (RESC) reset cause REG7 show SW, WDT1, BOR sticky bits & POR issues.

Genatco
Guru 55913 points
Other Parts Discussed in Thread: EK-TM4C1294XL

Since it is impossible for CCS5 debug to read the sticky bits of RESC REG 7 0x05c after the simulator aborts the DAP during an apparent SWR we add a register polling line into main application loop.

Below: The UARTprintf() shows the very same RESC bits enabled as does the CCS debug simulator, view register contents.

Polling the RESC it always prints 0x0000.0027 or [bits 5= WDT1, 2=BOR, 1=POR, 0=EXT].

WDT1 peripheral is not configured in 2 new Launch Pads and (RESBEHAVCTL) reset behavioral REG30, 0x1d8 are at the reset defaults.
If we explicitly disable WDT1 peripheral RESC [5] sill has WDT1 to be the reset cause. Possibly timing issues: SYSTICK = 120mHz/300 period (2.5us) 400Khz, maybe suspect in MPU soft resets while reading EEROM. We use F=1/P to determine the SYSTICK reset interval time is running 400Khz @2.5us. 

The MPU appears to randomly reset or abort functions in SW during looping reads of the EEROM. Often after hours breaks out of the while loop of the main application that invokes the EEROM read. Oddly LWIP TCP stack is still functional, console commands can be issued but re-invoking the main application loop that aborted causes an MPU reset. 

What is the minimum reset interval period SYSTICK can be programmed and still maintain integrity with EEROM and EMAC system peripherals?

Has any TI engineer stress tested this MPU integrity with such short STYSTICK periods?

Why does WDT1, BOR show as set when LM-Flash 1613 forces a reset after flash program?

  • 0
    TI__Guru**** 244400 points
    Hello BP101,

    The RESC registers need to be cleared for any logging to be valid after a reset cycle. The register is only cleared if there is a Power Cycle or a System Reset source like Pad, WDT with the behavior control register set as 0xFF. A CPU or soft reset shall not affect the cause register.

    What is interesting is the BOR reset bit is set which indicates that power supply is drooping and causing a reset of the device. You may want to ensure that enough current is being sourced to the device at 3.3V to not overload the regulator.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,

    Always assumed BOR was caused during initial power up of the Launch Pad via USB plug in to computer. BOR was set even in Debug register review. That sill does not address why WDT1 is always set with every POR. Find WDT1[5] being set when this Launch pad only recently made the WDT1 peripheral enabled, sleep enabled. Never configured the actual WDT1 peripheral timeout period. So how can it issues a timeout reset ?

    Register 7 (RESC) WDT1[5] When read, this bit indicates that Watchdog Timer 1 timed out and generated a reset.

    The computer USB individual plugs provide +5 @750ma from a MSI mother board.

    Back tracking 3.3v in schematic enters from the ICDI USB as VBUS P1, is renamed DBUG_VBUS/5.1B is then lost in schematic. JP1 is strapped pin 5 Target_Vbus/6.4A -to pin 6 VBUS and U4 pin 2 VBUS becomes +5 pin 7 powers U5 the 3.3 volt regulator. Some how the naming of the IDCI USB +5 supply voltage is not easily traced as JP1 Target_Vbus/6.4A is also a dead end in schematic. It appears VBUS from ICDI USB P1 bypasses JP1 as the power source to feed U5 pin 6 with +5. Totally lost in why JP1 even requires a jumper 5-6.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101,

    Simple experiment. Erase the entire flash code and power cycle the board. Then connect the Launchpad and check the register. It must show the value as 0x2 or 0x3 (the latter if the RST_N pin toggles during connect). If the RST_N pin can be disconnected momentarily then 0x2 shall come.

    The schematic for EK-TM4C1294XL is not as straight forward as other schematics. Note that USB power of 5V@750mA is max instantaneous current rating and not constant current. The actual constant current may be lower and during activity of the device may glitch enough to BOR the device.

    Regards
    Amit
  • 0 in reply to Genatco
    Guru 47900 points

    BP101 said:
    The computer USB individual plugs provide +5 @750ma from a MSI mother board.

    My belief - that unless yours is "non-standard" - 500mA was "normal/customary" current delivery (max) via USB.      And - as I know you to make/break that USB connection often during testing - might that USB cable have worn?      And - might other accessories or attachments stress your power rail - further?

    Very much that you (uniquely I'd say) report seems w/in the domain of a dipping supply voltage.      (as Amit first noted)       Might that simple fact have caused many (most/all) of your issues?      Pity if that's the case - power must be JOB #1!

    Perhaps Amit may comment if he finds many of your issues, "outside the norm" and thus likely to be caused by some fundamental power or set-up imperfection...

  • 0 in reply to Amit Ashara
    Guru 55913 points
    Power cycled launch pad, RESC now is reporting 0x3. The reset capacitor toggled pin 70. This is not the first time to power cycle this Launch Pad.

    Launch Pad was executing the application then randomly reset few minutes later, RESC= 0x11 bit 4 SW. Then few minutes latter several more random resets RESC=0x11 and the application again launched as if nothing went wrong.

    SW[4]: When read, this bit indicates that a software reset has caused a reset event.

    The odd thing is this application can at times run for 6 to 15 hours without any SW reset incidents. Testing application only and no SW Boot loader in this test. There are no SW reset routines in the application but many INT_MasterDisable/Enable in several routines. Is possible NVIC calls could some how be overlapping?

    Have notice if manually push reset button after POR the application often runs for hours without any random resets. Otherwise after many random CPU resets eventually stop for many hours.
  • 0 in reply to Genatco
    Guru 47900 points

    You may consider setting your scope to trigger upon a slight dip in voltage - monitor the most critical power & reset pins. Did not one of these new MCUs have a well known, "brown-out" issue?

    And - via use of "plain vanilla" 339 quad comparator - run from separate (and stable) supply - you may monitor 4 critical points in your system for "voltage dips."      Old analog manuals detail "how" you can "latch" that comparator's output - identifying which one(s) "fired."     I guarantee that if you build such a device - you'll use it again & again.      It's even possible to create two "window comparators" w/quad 339 - these trip when the measured voltage moves "outside" either a high or low "limit."

  • 0 in reply to cb1
    Guru 55913 points
    Confirmed RESC = BOR & WDT1 are both symptoms of LM-Flash Programmer attempting to assert the DAP whist application is running. That act also resets the MPU.

    My guess is ARM core raises Panic & asserts a SW reset via Sysctrl SRWD Register 68 (0x500). When the core is unable to reset the first peripheral in the list happens to be (WDT1) it causes MOSC latch up driving MPU reset and BOR indication.

    Now that is not the same reason code as SW RESC=0x11 but in the same ocean, appears ARM core can selectively pirate the ship and raise the black flag.

    Both launch pads are Brand new & cables and rarely unplug from USB.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101,

    If that indeed is the case for BOR, then it could be useful to have probe on VDD, VDDA an d VDDC to see what causes the BOR.

    As for the WDT1 when a Core Reset is asserted that will not cause a SRWD to be set as well. On the other hand a System Reset will cause all peripherals to be reset but will not cause a reset from the WDT as the clock is gated RCGC bits also will get cleared causing clock to the peripheral to be gated.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,
    see what causes the BOR.
    That BOR/WDT1 proved to be LM Flash invoking the DAP , I simply forgot to first press pad reset.
    If the pad is first reset pressing reset then LM Flash easily programs flash setting RESC 0x3. That stops WDT1 & BOR flags by adding a 1 second program delay after the MOSC has been configured giving GAP time for LMF to lock onto the DAP averting the BOR/WDT1 error.

    More interesting is RESC remains 0x3 during random application MPU resets, removing WDT0 configuration leaving only WDT0 peripheral enabled. In that case the MPU merely Halts and a manual reset is required where RESC bits again have cause to be SW 0x11. The application then randomly halts during copying EMAC DMA RX FIFO buffer writes into the ring buffer (ringbuf.c).

    The RESC SW bit is not clearly elaborated in datasheet from the way it is behaving in reality!
  • 0 in reply to Genatco
    Guru 55913 points
    RESC bits again have cause to be SW 0x11.

    Correction: After MPU halt and manual reset the RESC remains as 0x3.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    Based on the statement, I would presume, that the BOR is triggering during the application. Can you convert BOR not be a source of reset but an interrupt?

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

    Strange thing the Hibernation module is not enabled. Perhaps BOR is triggering because of defaults in RESETBEHAVCTL but only when the application is running.

    Without WDTO configured (FaultSR) traps during CCS debug when paused. The reserved state shows MPU Halt exception number 0000.00011 . Only guessing all exception types are hexadecimal values shown in table 2-8 page 114 of data sheet so that would infer exception SVCall ?

    SVCall = Software vector call and if so where to check what vector?

  • 0 in reply to Genatco
    Guru 55913 points
    New thread same issue:

    e2e.ti.com/.../1519806