• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 710 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1294KCPDT: Does preferred practice (unused HIB module pins) inhibit peripheral sleep enable commands sent to modules

Genatco
Guru 54057 points
Part Number: TM4C1294KCPDT

The HIB module for all purposes is seemingly disabled by conditions in both pin handling columns (acceptable / preferred) of table 26-7.  

Yet does the acceptable practice for unused HIB module pins (table 26-7) allow the HIB module to assert Tivaware peripheral sleep commands and put peripherals to sleep when commanded to do so? 

Or does the HIB module not have explicit control of the peripheral sleep function as logical deduction would have us think it should? 

Seemingly line powered peripheral sleep modes are not being disclosed in the datasheet HIB module section 7 or in the architectural overview section 1. 

  • 0
    TI__Guru 72500 points
    Hi BP101,
    Table 26-7 refers to unused pins. If Hibernate mode is to be used with internal power control, then the WAKE pin must be used to come out of hibernate mode (it is thus no longer an unused pin). I would not say that hibernate mode has control over the peripheral sleep modes. In the sleep modes, the clocks are controlled. In hibernate mode, power is removed.
  • 0 in reply to Bob Crosby
    Guru 54057 points
    Hi Bob,

    Kind of thought that might be the case having to enable clock gating for all peripherals but didn't know if something changed from Stellaris LM3S up to TM4C129x series that might inhibit sleep mode if the XOSC0 pin was grounded along with wake pin.

    Thanks that was a very clear and concise explanation for the two different modes...
  • 0 in reply to Bob Crosby
    Guru 54057 points

    Hi Bob,

    Bob Crosby said:
    In the sleep modes, the clocks are controlled. In hibernate mode, power is removed.

    Sub conscience bell is ringing, begs the question is not the purpose of peripheral sleep modes to reduce internal LDO power consumption? If so Is there really that much energy saved by sleeping the peripherals over hibernating them?

    Bit confusing HIB control module since bears deep sleep all winter long during hibernation. 

     

  • 0 in reply to Genatco
    Guru 117850 points

    Is not the, "Bear bare" - while w/in "deep sleep?" 

  • 0 in reply to cb1_mobile
    Guru 54057 points

    Point was the hibernation module seems an after thought added latter in MCU development not linked so much to sleep modes but only via NVIC wake up calls.

    Review of datasheet, system control registers set the various sleep modes of all oscillators, MOSC, PIOS etc.. with some exceptions wake up via Wait on Wake interrupt (WKONINT) or seemingly WAKE pin. I know from past experience the Wake pin being grounded & VBAT left floating seemingly has no issues with rouge WKONINT occurrence or otherwise unreported issues.

    However the preferred practice is to tie HIB module VBAT pin VDD, perhaps so the bear never is awakened by mistake yet why not ground VBAT since the HIB modules XOSC1 pin is grounded too?

    Perhaps unrelated but started having issues with EK1294-XL preforming firmware updates (RA2) via serial boot loader (SBL), would hang waiting ACK of magic packet as if the WKONINT failed to trigger the update semaphore & switch target over to FTP mode. Oddly the WKONINT seemed to function well (RA1) and seemingly quit working after loading nearly same firmware on a few RA2 launch pads. The firmware update mode INT syntax is being launched via Boolean switch call to function versus while(1) Boolean switch loop. Don't believe that should of had any effect of putting all enabled peripherals to sleep prior to WKONINT, yet the Boolean switch (firmware update=1) now calls the function.

    Didn't know may be related to sleep mode WKONINT until today, quit trying to debug SBL after others in forum reported hang issue. SBL hangs waiting for the host to ACK the BootP magic packet after seemingly an abrupt wakeup call or what should have been asserted by (SYSCTRL ?) as a wake on interrupt while invoking SBL.  The Hibernation module is fully functional on the launch pad even has a wake push button. The puzzle of SBL hanging may be related to peripheral sleep mode WKONINT being the firmware update mode in SBL is initiated via it's vector table having SW registered INT source and a (pseudo call) rapidly initiates target switching into FTP mode.