Stuck on HWREG(HIB_CTL) |= HIB_CTL_CLK32EN;

Haroldo Cazeao said:

portions of the code that are at play here between the old version and the new version are the same.    Not much difference.

Is it possible that your writing,  "are the same" - and then "Not much difference" - serves to  over-challenge your,  "would-be" helpers?      Now "sameness" - does not (necessarily) extend to "exactness" - so (some) difference (w/in sameness) may exist.     We're told that the "Devil is in the detail" - yet somehow - that detail has not arrived...

It is assumed that your code "sticks" while,  "waiting for  the write to "HIB_CTL" to complete."      Yet - to my mind - the (usual) "looping code which performs that "check for completion" - is not shown!"

Is it assured that all required "Set-Ups & Configures" (as demanded by Hibernate) have fully completed - prior to your call of  "HibernateEnableExpClk()?"      (you should be able to toggle a bit upon entering that function - proving that it was reached - and "started function execution."    

As your old code version ran fine - and new "sticks" - would it not make sense to, "Compare & Contrast both versions here - so that many may see & comment?"     This would appear superior to your report of,  "Not much difference" - when  "even the slightest difference" - may prove eventful!"

Hi cb1_mobile,

Thank you for your well-written reply. Your points are well taken.

At any rate, to  be more specific,  the only difference between the old version of the code that works on the new board  and the new version that sticks boils down to this:

1) With the old version, no boot loader was used.

2) With the new version, we use a boot laoder and the firmware starts running at offset 0x4000. 

3) Your assumption is correct,  the code "sticks" while,  "waiting for  the write to "HIB_CTL" to complete." 

Here's the exact code:

void
HibernateEnableExpClk(uint32_t ui32HibClk)
{
//
// Turn on the clock enable bit.
//
HWREG(HIB_CTL) |= HIB_CTL_CLK32EN;

//
// Wait for write complete following register load (above).
//
_HibernateWriteComplete();
}

Any ideas?

Thank you - your issue is clearer to "all here" (I believe) now.

Twas me - I'd (temporarily) bypass the boot-loader - and see if the "new" code succeeds.      "KISS" dictates that we ALWAYS start, "Simply!"       Proceeding in this manner will determine if the boot-loader has caused - or contributed - to your issue.      That's of key value - is it not?

Unanswered remains the,  "Proper Set-Up/Config. & Powering" of the Hibernate Module - prior to your function call.

It must be that "_HibernateWriteComplete();" contains the looping structure - neither firm nor I employ this vendor's boot-loader - thus I'm of little service in this regard.       As a "last gasp" - might the boot-loader - some way/how - confound this (completion) test?       (seems worthwhile pursuing - especially if the code runs properly when, "Freed from the boot-loader's embrace."       (i.e. KISS "avoids" such affection...)

Hi Ralph,

If I may - poster reported two boards - (past one succeeded) - should we not thus (trust) that his past "crystal/clocking" sits unchanged?      If such was altered - it was surely, "His Job" to detail that!

We (both) challenged his "Hibernation" Set-Up/Config - he did not respond to my request (or the Devil's) for such info...

Gents,

Sorry for the delay.

1) Here's the Hibernation module configuration setup.

/* Run from the PLL at 120 MHz. This waits for the PLL to * lock properly. */
sysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |SYSCTL_OSC_MAIN |SYSCTL_USE_PLL |SYSCTL_CFG_VCO_480 ), SYS_CLOCK_FREQ_HZ);

....

// Code CRC check
MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_CCM0); // Enable the CRC module

// Basic hardware setup

sysTickPeriodSet(sysClock / SYSTICKS_PER_SECOND); // (clocks/sec) / (tick/sec) = clocks/tick

SysTickIntEnable();
SysTickEnable();

....

   HibernateEnableExpClk(sysClock);    // Configure Hibernate module clock.

And here's the HibernateEnableExpCl

void
HibernateEnableExpClk(uint32_t ui32HibClk)
{
//
// Turn on the clock enable bit.
//
HWREG(HIB_CTL) |= HIB_CTL_CLK32EN;

//
// Wait for write complete following register load (above).
//
_HibernateWriteComplete();
}

2)  TI has the following errata with a work around 

HIB # 19 The first to the HIBCTL register may not complete successfully after a hibernation module reset.

3) Part of the workaround is to perform a software reset of the hibernation module? How do I do. I looked at hibernate.c from the driver lib. It's not readily apparent.

Hello Haroldo,

I don't see the following call: 

SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE);

That is a required API execution before you do anything else with Hibernate. It should be before your HibernateEnableExpClk call.

You also will need to configure the module clock source as well, such as a with an API call like:

HibernateClockConfig(HIBERNATE_OSC_LOWDRIVE);

If you look at our TivaWare hibernate example (closest example for your MCU would be in [Install Path]\TivaWare_C_Series-2.1.4.178\examples\boards\ek-tm4c1294xl\hibernate) you can see further details for setting up Hibernate module

As far as the Errata goes, I don't believe you are hitting that particular case. However for some details on it, please see this prior post from Amit: https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/408398/1448105#1448105

Hi Ralph,
Thank you for your prompt reply on this issue. Very much appreciated as this is becoming increasingly urgent.

Below is my entire code

main()
{
	sysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_480 ), SYS_CLOCK_FREQ_HZ);
	.....
	// ---------------------------------------------------------------------------------------------
	// Set interrupt priorities

	IntPrioritySet(INT_UART0 , UART0_INT_PRI );
	IntPrioritySet(INT_USB0 , USB_INT_PRI );
	IntPrioritySet(INT_ADC0SS2 , ADC0_SEQ2_INT_PRI);
	IntPrioritySet(FAULT_SYSTICK , SYSTICK_INT_PRI );

	.......

	// Basic hardware setup

	SysTickPeriodSet(sysClock / SYSTICKS_PER_SECOND); // (clocks/sec) / (tick/sec) = clocks/tick
	SysTickIntEnable();
	SysTickEnable(); // Enable the system tick. This should be
	// every ms.

	.......
	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE); // Enable the hibernate module.

	hib_Init(); // See blow for full implemenation

}




/**
 * This function initilizes the hibernation module in the MCU. If we are waking from hibernation
 * it resets the interrupt status. It also sets up the real time clock, but does not set the time.
 */

void hib_Init(void)
{
	uint32_t hibStatus = 0;

	HibernateEnableExpClk(sysClock); // Configure Hibernate module clock.

	// Check to see if Hibernation module is already active,
	// which could mean that the processor is waking from a hibernation.
	if(HibernateIsActive())
	{
		// Read the status bits to see what caused the wake. Clear the wake
		// source so that the device can be put into hibernation again.
		hibStatus = HibernateIntStatus(0);
		HibernateIntClear(hibStatus);
	}

	if(!(hibStatus & (HIBERNATE_INT_PIN_WAKE | HIBERNATE_INT_RTC_MATCH_0 |
			HIBERNATE_INT_GPIO_WAKE | HIBERNATE_INT_RESET_WAKE)))
	{
		HibernateClockConfig(HIBERNATE_OSC_HIGHDRIVE); // Configure the module clock source.
	}

	HibernateRTCEnable(); // Enable RTC mode.

	HibernateCounterMode(HIBERNATE_COUNTER_24HR); // Configure the hibernate module counter
	// to 24-hour calendar mode.

	HibernateRTCTrimSet(eep_RdAddr(RTC_TRIM_ADDR)); //Set the RTC trim register from eeprom

	return;
}

Hello Haroldo,

Thank you for sharing the full initialization. How about answers for these prior inquiries:

From a hardware side, few questions:

1. 1. Any hardware changes related to crystal/clocking?
   2. Is there an external crystal used for hib module?
      1. If yes, have you verified the schematic/layout for the crystal? (Guidelines: http://www.ti.com/lit/an/spma056/spma056.pdf)

I'll add one more now that I see your initialization code: What are the filter caps on your external crystal (if used)?

Hi Ralph,

Thank you for your reply. 

First, I did work with the HW engineer and we were able to scope the crystal to ensure it is operating as expected. 

Second, here are my answers to your questions:

1) does that mean that you were running the older firmware sans the boot loader on this new board?

Yes, a 2-year old version of the firmware where no boot loader was used runs 100% reliably on this new board. 

2) When you stepped through the code and got it running, was that with the boot loader?

Yes, it was with the boot-loader. But I must qualify "running". Only by stepping through the code was I able to get past the hibernation module.

3) what type of boot loader are you using? USB? UART?

USB.

Any other suggestions? I was going to start looking into the boot-loader

cb1_mobile said:

Twas me - I'd (temporarily) bypass the boot-loader - and see if the "new" code succeeds.      "KISS" dictates that we ALWAYS start, "Simply!"       Proceeding in this manner will determine if the boot-loader has caused - or contributed - to your issue.      That's of key value - is it not?

Boot-Loader - again & again - reveals itself as (very) "Prime suspect!"      Is it (really) needed?      Can its "advantage" (if any) justify the lost time/effort/expense?

All

I was able to root-cause the problem. It was not in the bootloader. The firmware was failing a voltage check and would subsequently go into hibernation mode would then lead to a software reset.

However, I do not want to close out his issue because there's a very important question still outstanding.

When using the source-level debugger, the code would hang when stepping over certain procedures. However, I do know the code works because if I don't step through it and let it run freely, everything works. The question becomes: how do I use the source-lelvel debugger without getting stuck when stepping over certain routines.