maqsudbek

could you provide the code you are using?
 
Also are you sure that it's transmitting at 33Khz?
I am not experienced with Serial IR but this i what i know of the tiva.
 
If instead of the low power mode you use normal mode, the frequency of the data being transmitted should be the same as a normal UART, you configure it the same, but remember to configure the CLK after calling UARTEnableSIR not never before.
 
in low power mode:
Operating in low-power IrDA mode adjusts the width of the infrared pulse transmitted to three  times the period of the internally generated baud clock.     Taken from the datasheet, page 914   The UARTILPR register stores the 8-bit low-power counter divisor value used to derive the low-power SIR pulse width clock by dividing down the system clock (SysClk). All the bits are cleared when reset.   The internal IrLPBaud16 clock is generated by dividing down SysClk according to the low-power divisor value written to UARTILPR. The duration of SIR pulses generated when low-power mode is enabled is three times the period of the IrLPBaud16 clock. The low-power divisor value is calculated as follows:   ILPDVSR = SysClk / FIrLPBaud16 where FIrLPBaud16 is nominally 1.8432 MHz.     Because the IrLPBaud16 clock is used to sample transmitted data irrespective of mode, the ILPDVSR field must be programmed in both low power and normal mode,such that 1.42 MHz < FIrLPBaud16 < 2.12 MHz, resulting in a low-power pulse duration of 1.41–2.11 μs (three times the period of IrLPBaud16). The minimum frequency of IrLPBaud16 ensures that pulses less than one period of IrLPBaud16 are rejected, but pulses greater than 1.4 μs are accepted as valid pulses.         I hope it helped, i never used any serial IR so i'm probably missing something

Ok so this was an idea that came to mind last night; These datasheets and related documents are huge, and sometimes have surprising & interesting details nestled into their labyrinth-like chapters.  Why not start a thread for sharing noteworthy details?  No need to be a pack of lone wolves about these things...
 
I'll start - with the TM4C123GH6PM datasheet: http://www.ti.com/lit/ds/symlink/tm4c123gh6pm.pdf
 
Reading through Chapter 2 yesterday, "The Cortex-M4F Processor", a few details stuck out that I hadn't realized before-
 
1. Didn't realize there is a 16-bit SIMD vector processing unit.  How do you access/use it from GCC I wonder?
 
2. Debug - SWV, Serial Wire Viewer, is a feature where you can export a stream of software-generated messages, data trace, profiling information.  Software-generated messages -- How do we access that?  I assume we need OpenOCD to use this feature, but is there an API for writing to this debug interface?
 
3. Like most complicated processors, there is a notion of "privileged" vs "unprivileged" execution modes.  The Cortex-M4F extends this further by declaring two operational modes too--"Thread" mode (i.e. normal application runtime, either privileged or unprivileged) and "Handler" mode, exclusively privileged and only available as the context for ISR handlers.
 
4. Coming from MSP430 land, I'm always looking for analogies to the MSP430 in here.  The equivalent for the "GIE" (global interrupt enable) bit is the PRIMASK register; when bit0 is set, it disables all interrupts (of configurable priority, so RESET/NMI/Fault interrupts still fire).  This is important for sleep modes below...
 
5. Interrupt priorities run from 0-7, with *lower* numbers being of "higher" priority.  Default priority for all interrupts is 0 (the highest).  BASEPRI register declares the minimum priority required to fire, and besides setting 0 (=no exceptions masked), the setting masks all interrupts of that priority and those higher in number ("lower" in priority).
 
6. The CONTROL register has an interesting bit, "FPCA", which will adjust the latency for entering an interrupt ISR; it determines whether or not the Floating Point Unit's registers should be pushed onto the stack during ISR entry or not.  This makes a substantial difference, as seen on page 109; the difference between FPCA=1 exception frame and FPCA=0 exception frame is many-fold.  So folks not using floating point would do well to keep that disabled (not 100% sure how GCC handles this yet, i.e. whether there's a builtin, a TivaWare ROM_* function or if you have to do an inline ASM code).
 
7. Bit-banding is available for everything; flash, SRAM, peripherals.  I think TivaWare has some macros to make that easy, need to look into it.  It's a feature for doing single atomic writes or reads to a single bit of any byte in the address space, by writing/reading a 32-bit word (0x00000000 for bit 0, 0x00000001 for 1).
 
8. The Cortex-M4F provides two user IRQs for operating system support; SVCall (Supervisor Call) and PendSV (pendable, interrupt-driven request for system-level service--typically used for context switching).
 
9. Sleep modes.  The Cortex-M4F uses instruction-based sleep entries, but it has some features that allow the MSP430's "event driven" paradigm too.
9a. WFI = Wait For Interrupt, goes to sleep and will wake up only if an unmasked interrupt occurs.
** Sometimes waking requires a common "clean-up" or reinitialization routine to run; to support this, your app would enter WFI inside an idle loop with PRIMASK enabled so that the CPU wakes up, but does not enter the ISR right away; does its cleanup work; then disables PRIMASK so the Cortex immediately jumps to the highest-priority IRQ's ISR.
9b. WFE = Wait For Event, goes to sleep and will wake up if ANY interrupt occurs, even if it's masked; If it is masked, the CPU will not branch to its ISR but just continue from the point where the WFE instruction occurred.  If it is unmasked, then the CPU will jump to the ISR immediately.
9c. Sleep-on-Exit; if the SLEEPEXIT bit of SYSCTRL is set, then the CPU will return to sleep mode after servicing ISRs.  Similar to MSP430's LPM modes if the ISR does not issue a __bic_SR_register_on_exit(LPMx_bits); type of call.
 
That's all for now.  Chapter 3 later today.

Just a bit of explanation on how to use the Prescaler Match:
 
in PWM mode the prescaller holds the most significant bits, working as a timer extension.
 
if you have a wide timer in PWM, it has 32bits and the prescaler has 16bits. If you have the Load value of the timer at 0 and the prescaler value at 1, then it means you have a number of 48bits, witht the 32st bit being 1, number 4294967296, At 80Mhz this would mean that the timer would have a period of
1/80Mhz * 4294967296  53s, less than 0.02Hz.
 
The use of the prescaller for the wide timer in PWM mode will generally not be the most useful since the wide timer is alredy 32bits and can make any PWM low frequency starting at 1Hz, for the normal timers (which are 16bits in pwm mode) it's more useful to do something like control a servo which requires 50Hz PWM, something impossible with a 16bit timer with a source of 80Mhz system clock.
 
If you want to set a match, which in PWM mode is when a signal turns from 1 to 0, setting the duty, you need to not only use TimerMatch, but also do so for the prescaler. This is because TimerMatch only sets the match for the 32bits of the timer, for the prescaler bits you need to change other register (hence the different function).
 
Now the 2s blink.
If you want the LED to change state every 2 second you can set the PWM to a period of 4s, and a duty of 50%, this will make it change from 1-0 and back to 1, every 2s.
At 40MHz, you do 4s * 1/40Mhz = 160000000, which needs 40bits, so the prescaler is needed. This number needs in the prescaler the value 0x9 and in the timert the value, 0x896800 - 1 (-1 because, remember tha the 0 counts). These are the load values.
Now to set the duty to 50%, you have the (160000000-1) /2 = 79999999,5, lets say just 79999999. It's 0x4C4B3FF, which has values in the prescaler. So we do prescaler match with 0x4 TimerMatch with 0xC4B3FF.
With this you have a LED that changes state every 2s by using a 4s period PWM.
 
If you actually need the led to every 2s to do a short blink, i think you now see how the prescaller works to do that.

PWM is much easier on the new Launchpad using the PWM peripherals, here is a working example using the 3 onboard LEDs.
#include <stdint.h> #include <stdbool.h> #include "inc/hw_gpio.h" #include "inc/hw_types.h" #include "inc/hw_memmap.h" #include "driverlib/sysctl.h" #include "driverlib/pin_map.h" #include "driverlib/gpio.h" #include "driverlib/pwm.h" int main(void) { unsigned long ulPeriod; //Set the clock SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ); //Configure PWM Clock to match system SysCtlPWMClockSet(SYSCTL_PWMDIV_1); // Enable the peripherals used by this program. SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF); SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM1); //The Tiva Launchpad has two modules (0 and 1). Module 1 covers the LED pins ulPeriod = SysCtlClockGet() / 200; //PWM frequency 200HZ //Configure PF1,PF2,PF3 Pins as PWM GPIOPinConfigure(GPIO_PF1_M1PWM5); GPIOPinConfigure(GPIO_PF2_M1PWM6); GPIOPinConfigure(GPIO_PF3_M1PWM7); GPIOPinTypePWM(GPIO_PORTF_BASE, GPIO_PIN_1 | GPIO_PIN_2 | GPIO_PIN_3); //Configure PWM Options //PWM_GEN_2 Covers M1PWM4 and M1PWM5 //PWM_GEN_3 Covers M1PWM6 and M1PWM7 See page 207 4/11/13 DriverLib doc PWMGenConfigure(PWM1_BASE, PWM_GEN_2, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_NO_SYNC); PWMGenConfigure(PWM1_BASE, PWM_GEN_3, PWM_GEN_MODE_UP_DOWN | PWM_GEN_MODE_NO_SYNC); //Set the Period (expressed in clock ticks) PWMGenPeriodSet(PWM1_BASE, PWM_GEN_2, ulPeriod); PWMGenPeriodSet(PWM1_BASE, PWM_GEN_3, ulPeriod); //Set PWM duty-50% (Period /2) PWMPulseWidthSet(PWM1_BASE, PWM_OUT_5,ulPeriod/2); PWMPulseWidthSet(PWM1_BASE, PWM_OUT_6,ulPeriod/2); PWMPulseWidthSet(PWM1_BASE, PWM_OUT_7,ulPeriod/2); // Enable the PWM generator PWMGenEnable(PWM1_BASE, PWM_GEN_2); PWMGenEnable(PWM1_BASE, PWM_GEN_3); // Turn on the Output pins PWMOutputState(PWM1_BASE, PWM_OUT_5_BIT |PWM_OUT_6_BIT|PWM_OUT_7_BIT, true); //Do nothing while(1) { } }

Hi guys!
 
So i made a blog. Since i am the only in the robotics club that uses TI devices i was asked to teach about the Tiva. Well, what i can at least. And I'll post in the blog all the codes and tutorials.
 
It's still very early under-construction and will be something i will be doing along the school year. I am teaching it to some colleagues and will before the sessions, post the tutorials and some codes, but also post more codes after as examples. I will post basic info about the peripherals.
 
I hope it helps anyone that needs it. Also any feedback is appreciated, teaching someone live is different and i can forget some details while writing. Also i never done something like this, i usually do give lots of explanations but always live and more exercise driven.
 
Blog:
https://sites.google.com/site/luiselectronicprojects/tutorials