TM4C1230H6PM: I can't get other bits of PORT B to turn on LEDs

Marco Lugo

Part Number: TM4C1230H6PM

Hi, I am using the EduBase ARM Trainer together with the LaunchPad. According to one of the diagrams the LEDs are connected to PORT B but only PB0 is turning on:

Here is the code I have, I'm running this on Keil uVision5:


Lab4_2.h
*******************************************************

#include <stdint.h>
#include <stdbool.h>

#define SYSCTL_RCGC2_R 			(*((volatile uint32_t*)0x400FE108))
#define GPIO_PORTB_DATA_R		(*((volatile uint32_t*)0x400053FC))
#define GPIO_PORTD_DATA_R		(*((volatile uint32_t*)0x400073FC))

#define SYSCTL_RCGC2_GPIOB	0x00000002	// Port B Clock Gating Control
#define SYSCTL_RCGC2_GPIOD	0x00000008	// Port D Clock Gating Control


Lab4_2.c
*******************************************************

#include "Lab4_2.h"
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "driverlib/gpio.h"
#include "driverlib/sysctl.h"

int main(void) {
	uint32_t ui32Input;
	bool res;
	
	// Set up the clock
	SysCtlClockSet(SYSCTL_SYSDIV_10|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);
	
	// Enable the GPIO PROTB & PORTD
	SYSCTL_RCGC2_R = SYSCTL_RCGC2_GPIOB|SYSCTL_RCGC2_GPIOD;
	
	// Set PB0-PB3 as an output pins
	GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_3);
	GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_2);
	GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_1);
	GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_0);
	
	// Set PD0-PD3 as an input pin
	GPIOPinTypeGPIOInput(GPIO_PORTD_BASE, GPIO_PIN_3);
	GPIOPinTypeGPIOInput(GPIO_PORTD_BASE, GPIO_PIN_2);
	GPIOPinTypeGPIOInput(GPIO_PORTD_BASE, GPIO_PIN_1);
	GPIOPinTypeGPIOInput(GPIO_PORTD_BASE, GPIO_PIN_0);
	
	// Check whether both ports are ready to be accessed
	res = SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOB) | SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOD);
	
	if (res) {
		while(1) {
			ui32Input = GPIO_PORTD_DATA_R;
			
			// If DIP-SW1 is pressed turn on LED
			if ((ui32Input & 0x8) == 0x8) {
				GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_0, 0x1);
				GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_1, 0x1);
				GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_2, 0x1);
				GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, 0x1);
				SysCtlDelay(500000);
				GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_0, 0x0);
				GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_1, 0x0);
				GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_2, 0x0);
				GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_3, 0x0);
				SysCtlDelay(500000);
			}			
		}
	}
}

Is there something I'm missing?

Thank you.

over 8 years ago

0 cb1_mobile over 8 years ago

Guru 117855 points

Greetings,

Without even reading your post (i.e. noting (only) your nicely descriptive "Subject Line") myself/likely others - "just KNEW your issue!" (and surely a simple, instant cure...)

This is one occasion where your past experience - and expectations - prove, "Not your friend!" And - this issue indicates that you've not had much time to review (hundreds) of forum posts (via the forum "Search Box" (atop this forum page) which proves of great value to new users.)

One method of "general troubleshooting" is to review, "What's common (even "if" something is common) among problem code and/or hardware designs." You well note that (only) PB0's Led illuminates. Thus that "code & hardware connection" is most likely correct! Let's now examine your code:

"GPIOPinWrite("desired Port", "desired pin(s)", "Value ascribed to that/those pin(s)")"

What's common among "all three" failed Port_B writes is the use of "0x1" - in "hopes of turning on that Port bit. (and connected Led) And that works for PB0 - but NOT for your 3 other Port B pins. (nor for ANY other Port B pins!)

That final (3rd) parameter w/in "GPIOPinWrite()" must hold the, "Bit Weighted Value" of the "desired, Port pin." Thus PB0 does work as "0x1" IS its bit-weighted value! (and - unfortunately ONLY the proper value for PB0's "On State!)

To turn on "other" pins (i.e. PB1) employ its bit weighted value (0x2) - likewise PB2 (0x4) and so on. Multiple bits (all yours shown here) turn on w/parameter 3 set to 0xF (or simply 15).

In many other protocols the use of "0x1" indeed, "Sets the bit." But not here. There IS an advantage to this method! (first introduced by the predecessor MCU firm "LMI".) You should be able to consider & determine that - if interested.

Your review of the "Peripheral Driver's User Guide" and the many code examples: vendorWare/examples/peripherals, provides great insight & speeds/eases your learning... Bon Voyage!

Arm-based microcontrollers

Arm-based microcontrollers forum

TM4C1230H6PM: I can't get other bits of PORT B to turn on LEDs