It's me again. I'm now working on Lab 6 of the Tiva C Workshop series. I got through Lab 5 (ADC) without any problems, which was great. Now I'm stuck again. I really can't figure out what the problem is this time -- I've read and re-read all the API function info in the Peripheral Driver Library User's Guide to see if I was causing problems like in Lab 4, i.e. some functions are different with the TM4C129X series as opposed to TM4C123G. However, in this case, that doesn't seem to be the case.
Here's my code so far. Note that I've commented out the rom.h and TARGET_IS_SNOWFLAKE_RA0 because I wanted to make sure that wasn't the problem. I just learned how to call the API from ROM in the last lab, and I wanted to try and apply that right away to this lab (though it's not a part of the lab instructions) just as a learning experience. But I commented that out and removed all the ROM_ prefixes just in case. In the HibernateEnableExpClock() function call, I remembered that in my other thread I was told that the Snowflake devices do not support SysCtlClockGet() function, so I simply entered the 40MHz as a constant. BTW -- is there any where to get the clock value through an API call or otherwise? It seems really strange that they removed that API call for the 129X devices but then didn't supply an alternative.
#include <stdint.h>
#include <stdbool.h>
#include "utils/ustdlib.h"
#include "inc/hw_types.h"
#include "inc/hw_memmap.h"
#include "driverlib/sysctl.h"
#include "driverlib/pin_map.h"
#include "driverlib/debug.h"
#include "driverlib/hibernate.h"
#include "driverlib/gpio.h"
//#define TARGET_IS_SNOWFLAKE_RA0
//#include "driverlib/rom.h"
int main(void)
{
SysCtlClockFreqSet(SYSCTL_OSC_INT|SYSCTL_USE_PLL|SYSCTL_CFG_VCO_480, 40000000); // set system clock to 40MHz
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOQ); // enable Port Q GPIO
GPIOPinTypeGPIOOutput(GPIO_PORTQ_BASE, GPIO_PIN_7); // set PQ7 to output
GPIOPinWrite(GPIO_PORTQ_BASE, GPIO_PIN_7, 0x80); // turn LED on
SysCtlPeripheralEnable(SYSCTL_PERIPH_HIBERNATE); // enable hibernation
HibernateEnableExpClk(40000000); // set clock to system clock
HibernateGPIORetentionEnable();
//HibernateClockConfig(HIBERNATE_OSC_LFIOSC); // set LFI as clock source in hibernation
SysCtlDelay(64000000); // delay long enough to see the LED
HibernateWakeSet(HIBERNATE_WAKE_PIN); // set wake condition to wake pin
GPIOPinWrite(GPIO_PORTQ_BASE, GPIO_PIN_7, 0x00); // turn LED off before going to sleep
HibernateRequest();
while(1)
{
}
}
The HibernateClockConfig() is also not part of the lab, but I experimented with adding it in to see if if helped.
Essentially, here's what's supposed to happen -- when the micro powers up, it turns on an LED, then enables the hibernation module, and as soon as the HibernateRequest() happens, it turns the LED off. It then is supposed to stay in hibernation until the /WAKE pin goes low. This board (unlike the 123G Launchpad) does not have a button connected to the /WAKE pin, so I simply took the header pins onto a breadboard, and used a 1k pull-up resistor to keep /WAKE high. Then, when the button is pressed, it goes low and should in theory wake the micro.
What's happening though, is after the delay, there's a brief flicker in the LED, then it comes back on fully, and the debugger loses communication with the board. The flicker keeps happening every four seconds or so (the length of the delay function). Occasionally, the LED will turn off and the chip will go into hibernate mode. Pushing the button 'wakes' the chip but then instead of going back into hibernation after four seconds it does the same infinite loop as I just described, with the LED flickering every four seconds, and the board losing contact with the debugger.
Am I missing something obvious here? Again, all help is truly appreciated! Thanks in advance.
