Jump to content
Sign in to follow this  

Using Hardware PWM on Tiva Launchpad

Recommended Posts

@@brownfox Using PMW on Energia should be easier.


Just try something like this as an example:

#define FREQ 50000 //Hz
#define PIN PD_0 //pin D0

void setup(){


void loop(){
  int i=0;
  analogWrite(PIN, i);
  i = (i + 1) % 256;


Share this post

Link to post
Share on other sites



Thank you  Gonya707


I know this way of getting pwm on energia but I wanted to use pwm capability of TM4C123GH6PM.


I am sure it is possible but I am not skilled enough to deal with,  although I  learn every day .


so far I get a white LED ( mix of rgb )


May be the clock speed ... I wonder if clock speed (80 Mhz)  can be changed on Energia .



Share this post

Link to post
Share on other sites


To have alternate pins functions available, you must take two actions:

1) insert this: #include "driverlib/pin_map.h" at the beginning of your file;

2) check to have defined both PART_LM4Cxxxxx (write here the exact type of your micro) and TARGET_IS_BLIZZARD_RA1. The last one is useful in calling ROM_ prefixed functions.


But above all, first you need to check if your micro has the PWM module, since it is not present on all devices, even these has the same number of pins.



Share this post

Link to post
Share on other sites

@@Lyon Thanks, but I'm still missing something with this;

I put 1) at the very top of the project instead of later, to try that

2)are both included in my Makefile, PART=TM4C123GH6PM, as copied from my Tiva board's examples.

built and flashed again, no change in LEDs from earlier. Ran make clean before make...

Share this post

Link to post
Share on other sites


I checked the posted code and compile correctly, with shown settings. I have slightly modified it, to allow ROM functions calls. The tested version is this:


#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"
#include "driverlib/rom.h"

{ unsigned long ulPeriod;


//Set the clock

//Configure PWM Clock to match system

// Enable the peripherals used by this program.
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM1); //The Tiva Launchpad has two modules (0 and 1). Module 1 covers the LED pins
ulPeriod = ROM_SysCtlClockGet() / 200; //PWM frequency 200HZ

//Configure PF1,PF2,PF3 Pins as PWM

//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

//Set the Period (expressed in clock ticks)
ROM_PWMGenPeriodSet(PWM1_BASE, PWM_GEN_2, ulPeriod);
ROM_PWMGenPeriodSet(PWM1_BASE, PWM_GEN_3, ulPeriod);

//Set PWM duty-50% (Period /2)
ROM_PWMPulseWidthSet(PWM1_BASE, PWM_OUT_5,ulPeriod/2);
ROM_PWMPulseWidthSet(PWM1_BASE, PWM_OUT_6,ulPeriod/2);
ROM_PWMPulseWidthSet(PWM1_BASE, PWM_OUT_7,ulPeriod/2);

// Enable the PWM generator

// Turn on the Output pins

//Do nothing



For the next several days I do not have an board available to test it...

The settings are here:


// tried to post a picture, but seems to not work… 



Check again - or at least post the errors or some settings.


Share this post

Link to post
Share on other sites

Same light, no change. This is the output I'm getting, and the makefile ("non-restricted" not a copy of TI's; that may be where I'm over my head here).

zadok@new-host-3 tiva_pwm]$ make

Compiling tiva_pwm.c...
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -O0 -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic -c -g -I ../../../../ -DPART_TM4C123GH6PM -c -DTARGET_IS_BLIZZARD_RA1 tiva_pwm.c -o tiva_pwm.o

Compiling startup_gcc.c...
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -O0 -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic -c -g -I ../../../../ -DPART_TM4C123GH6PM -c -DTARGET_IS_BLIZZARD_RA1 startup_gcc.c -o startup_gcc.o

Compiling LM4F_startup.c...
arm-none-eabi-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -O0 -ffunction-sections -fdata-sections -MD -std=c99 -Wall -pedantic -c -g -I ../../../../ -DPART_TM4C123GH6PM -c -DTARGET_IS_BLIZZARD_RA1 LM4F_startup.c -o LM4F_startup.o
LM4F_startup.c:72:5: warning: ISO C forbids initialization between function pointer and 'void *' [-pedantic]
LM4F_startup.c:72:5: warning: (near initialization for 'myvectors[0]') [-pedantic]

Making driverlib
make -C ../../../../driverlib/
make[1]: Entering directory `/home/zadok/tools/driverlib'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/zadok/tools/driverlib'

arm-none-eabi-ld -T LM4F.ld --gc-sections -o main.axf tiva_pwm.o startup_gcc.o LM4F_startup.o ../../../../driverlib/gcc-cm4f/libdriver-cm4f.a /home/zadok/tools/gcc-arm-none-eabi-4_7-2013q3/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/lib/armv7e-m/softfp/libm.a /home/zadok/tools/gcc-arm-none-eabi-4_7-2013q3/bin/../lib/gcc/arm-none-eabi/4.7.4/../../../../arm-none-eabi/lib/armv7e-m/softfp/libc.a /home/zadok/tools/gcc-arm-none-eabi-4_7-2013q3/bin/../lib/gcc/arm-none-eabi/4.7.4/armv7e-m/softfp/libgcc.a

arm-none-eabi-objcopy -Obinary main.axf main.bin

Creating list file...
arm-none-eabi-objdump -S main.axf > main.lst
[zadok@new-host-3 tiva_pwm]$ sudo lm4flash main.bin
[sudo] password for zadok:
Found ICDI device with serial: 0E20092F
ICDI version: 9270


Share this post

Link to post
Share on other sites


There some problems with your project:
1) You do not need two initializations files, namely startup_gcc.c and LM4F_startup.c. Remove the last one from your project and keep only that from TI (although small changes are needed, later…). As you note, you get some warnings, while the first one compiles OK.
2) Do not know what is LM4F.ld - if from the same author like Makefile, then could be buggy, and bugs shows up when used on little bit more bigger/complex projects than blinky one.
3) The linker must be called from gcc, not directly - this is the recommendation and the good practice. Good to pass the switch -nostartfiles, since you provide your own in startup_gcc.c
4) The Makefile uses some settings from TI for working with floating point (uses softfp libraries) - for this project may not be important, but if really using fp, the hardfp library could be an advantage (is smaller than softfp).
5) The paths: I do not know where this project is created - TI recommendation is to be done inside StellarisWare/TivaWare folder - so if yours is not there, again, the paths shown in Makefile could cause problems. I do not use TI recommendation, made the project elsewhere and add the right path. Correct yours, add them to Makefile (where points this: STELLARISWARE_PATH=../../../../  ??).
6) If you prefix your calls with ROM_ as I have done, then you do not need to compile/link the driverlib, since it is included on-chip.
7) A much more easier approach is to use Eclipse+GCC - together with GNU ARM Eclipse  plug-in (from here: http://sourceforge.net/projects/gnuarmeclipse/)- you do not need to write Makefiles, all this process is managed by the plug-in (it is called "managed make"). 
8) If you will get warnings from compiling startup_gcc.c, I will tell you how to avoid them.

Share this post

Link to post
Share on other sites

Thanks! I'm doing Eclipse/gnu plugin now. (I think I got the eclipse project I made to use it; at least it is installed)  Having problem with startup.gcc;  finding includes, but its giving errors on an asm block for Zero fill the bss segment.

Share this post

Link to post
Share on other sites

Got it down to just this error:

../gcc-lk-start/startup_gcc.c: In function ‘ResetISR’:
../gcc-lk-start/startup_gcc.c:293:5: error: unknown type name ‘uint32_t’

when I know that 'uint32_t' is defined in the project. I'm using the startup_gcc.c you provided above. Is it my learning curve taking time, or some change needed in that file?

Share this post

Link to post
Share on other sites


This is strange since the function ResetISR does not use uint32_t at all. The only place could be the definition of HWREG itself - but for the moment I am in a short time and cannot check, i will do that in several hours to come. In the mean time, you have two possible solutions:

1) add these lines at the beginning of the startup file:

#include <stdbool.h>
#include <stdint.h>
and check them for the uint32_t first before compiling;
2) instead the two lines above, you can use:
#define uint32_t unsigned long

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Create New...