EKS-LM4F232 blinky project ported to CCS5.1 with modifications

John Osen

I have ported the EKS-LM4F232 blinky project to CCS5.1. I have now made a very simple edit. It has problems. I have phyiscally attached an LEDs to PK0-3. I am now trying to have PK2 follow the blinking of the standard PG2. There are five additional lines of code. Three to set up the port. And two to toggle the output. Here is what happens:

1) launch the debugger

2) start the program, no blinking

3) suspend the program and find yourself at the fault ISR after executing "GPIO_PORTK_DIR_R = 0x0F;" (can also get here be stepping from the beginning)

4) restart the program by using the restart button, get past the above instruction but then hang (and I mean no step instruction does anything, it is as if the debugger does not know what to do with the step command) at the "GPIO_PORTK_DATA_R |= 0x04;" instruction.

5) cannot get past this point

The modified main is below. I suspect that all you would need is the stock EKS to duplicate this issue.

int

main

(void)

{

volatile unsigned long ulLoop;

// Enable the GPIO port that is used for the on-board LED.

SYSCTL_RCGC2_R = SYSCTL_RCGC2_GPIOG;

// Do a dummy read to insert a few cycles after enabling the peripheral.

ulLoop = SYSCTL_RCGC2_R;

// Enable the GPIO pin for the LED (PG2). Set the direction as output, and

// enable the GPIO pin for digital function.

GPIO_PORTG_DIR_R = 0x04;

GPIO_PORTG_DEN_R = 0x04;

// Enable K0-3 as outputs

GPIO_PORTK_AFSEL_R = 0;

GPIO_PORTK_DIR_R = 0x0F;

GPIO_PORTK_DEN_R = 0x0F;

// Loop forever.

while(1)

{

// Turn on the LED.

GPIO_PORTG_DATA_R |= 0x04;

GPIO_PORTK_DATA_R |= 0x04;

// Delay for a bit.

for(ulLoop = 0; ulLoop < 200000; ulLoop++)

{

}

// Turn off the LED.

GPIO_PORTG_DATA_R &= ~(0x04);

GPIO_PORTK_DATA_R &= ~(0x04);

// Delay for a bit.

for(ulLoop = 0; ulLoop < 200000; ulLoop++)

{

}

over 13 years ago

0 slandrum over 13 years ago

Mastermind 9890 points

You enable port G, but you don't enable port K. Any reference to port K hardware registers will fault if the peripheral is not enabled.

0 cb1_mobile over 13 years ago

Guru 117855 points

SLandrum is correct - you require...

SYSCTL_RCGC2_R = SYSCTL_RCGC2_GPIOG | SYSCTL_RCGC2_GPIOK ;

Beware - as Port K is AHB it may have different designator... and - as I look further at this issue: Port K appears to be AWOL!

In my/firm's infinite wisdom we've avoided this issue by using 64 pin version of M4F - devoid of Port K. Time for you/we to "better" RTFM... And after yet another read/review the following is revealed:

And your earlier cross-post showed:

// Enable the port and enable PK0-3 as outputs

SYSCTL_GPIOHBCTL_R = 0x20;

GPIO_PORTK_DIR_R = 0x0F;

GPIO_PORTK_DEN_R = 0x0F;

You appear to have everything that you could do - except you have violated the delay provision between SYSCTL() and that Port Access - as I earlier stated... Insert a delay just prior to GPIO_PORTK_DIR_R and see if that resolves...

Interesting (and unfortunate) that not one example w/in EK-LM4F232 sought to use this Port K...

0 Sue Cozart over 13 years ago in reply to cb1_mobile

TI__Guru 58650 points

Hi cb1_mobile,

You are right on with your caution for Port K being only available on the AHB. You are also right about a better reading of the manual. If you look at the note above the snap shot you posted, you'll see that the "old" RCGC registers only work for legacy peripherals.

To enable the clock for Port K, you must use the RCGCGPIO register.

If you use StellarisWare, the SysCtlPeripheralEnable() function takes these changes into account and sets the appropriate bits to enable each peripheral.

Regards,

Sue

0 cb1_mobile over 13 years ago in reply to Sue Cozart

Guru 117855 points

Hi and greetings to you, Sue:

Always welcome/enjoy your comments - thanks for assisting once again. Forgive me - must say that even after several s l o w readings - the fact that Reg: RCGC2 only works for legacy peripherals does not exactly "jump out." (obscured I think by the volume of - imho - much less significant information) The sentence, "To support legacy software, this register is available," (2nd sentence after Important) really could/should be more prominent - and worded more directly. (register is available - how nice - way too passive for this reporter!) Doubt/pray not that you were the author.

To solve original poster's issue - appears:

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOK); // if I understand correctly.

There is some dispute regarding requirement for some delay immediately following this statement. (valued poster slandrum & I have crossed swords on this) Using IAR I am often able to operate "error/warning" free with no delay - even though DRL_UG and MCU datasheet caution otherwise. (I'm usually @ 50MHz and above - using paid IAR 6.30)

Thanks again for this and your many valuable contributions to this forum...

0 John Osen over 13 years ago in reply to Sue Cozart

Genius 3585 points

Sue, Thanks for the answer. It got me moving.

I know writing a Chip UG that is ~1500 pp long and a API UG that is ~500 is a huge task. TI has done well. But the sad fact is nobody "reads" manuals anymore, they scan them with expressions. Often the expressions used come from quick reading of the example code. I scanned mine using "PortK" not "Port%20K". Once I used the latter, I found the references to which you made.

I believe the GPIO register you reference uses Rn as bit definitions, where registers that have similar bits used Portn as bit definitions. A R9 to enable PortK is not likely to get a search hit :) I pity the writers, they not only have to get the technical content in there, but think about search keywords.

Your reference to a StellarisWare call was great. (The blinky code is a StellarisWare free example. The next simplest example, hello, is StellarisWare aware.) Thanks for nudging me down that path.

0 slandrum over 13 years ago in reply to John Osen

Mastermind 9890 points

I have a feeling that the blinky demo was written before DriverLib existed, and was originally written for the first generation Stellaris processors. What's unfortunate is that it is often the example that people start with to modify to begin their projects.

It should be updated to make StellarisWare calls, or at least have comments added to it suggesting that it's not the best example to base your project on if you are using one of the newer class of parts.

0 cb1_mobile over 13 years ago in reply to slandrum

Guru 117855 points

slandrum said:
It should be updated to make StellarisWare calls

Or not - your logic is persuasive - but the brief, direct register writes "insulate" new user from clock setting disasters! (which are usually fatal for basic, unrecoverable Sandstorm MCUs you/I have past used.)

Surely more comments/detail are required (especially do NOT monkey with JTAG pins!) (what's JTAG?)

0 Sue Cozart over 13 years ago in reply to cb1_mobile

TI__Guru 58650 points

Actually, DriverLib has been part of the Stellaris offering since the very beginning. Employee number 4 at Luminary Micro (the first one after the 3 founders) was a software engineer whose goal was to make it easy to write software for Stellaris!

blinky is written using register writes to show how to write software using this method. We encourage the use of the DriverLib, which is why all other examples are done using DriverLib. If an engineer wants to use direct register writes, liberal use of the header files is required in order to know what parameters are vaild.

Regards,

Sue

0 cb1_mobile over 13 years ago in reply to Sue Cozart

Guru 117855 points

@Sue,

Good to know - hazard a guess that #4 was one S.C...

0 Sue Cozart over 13 years ago in reply to cb1_mobile

TI__Guru 58650 points

That's kind of you to say, cb1, but no - employee #4 is someone far more awesome than me!

Sue

Arm-based microcontrollers

Arm-based microcontrollers forum

EKS-LM4F232 blinky project ported to CCS5.1 with modifications