CCS/TM4C123GH6PM: #10247-D null: creating output section

Your project doesn't contain a linker .cmd file. It is the linker command file which specifies the placement of sections in memory regions.

With no linker command file the linker produces warnings of the form 'creating output section ".stack" without a SECTIONS specification', and picks an arbitrary memory region to place the sections. This can cause a failure at runtime, e.g. if the linker places the stack into flash.

When you create a new project for a tm4c123gh6pm by default CCS should add the tm4c123gh6pm.cmd linker command file. If you go to the General project properties you should be able to select a linker command file for the device:

See TI Linker Command File Primer for some background information.

halo said:

Do you have any recommendations about my other question, the order of calls for initialising a peripheral Port?

The SysCtlPeripheralPowerOn() function modifies the Peripheral Power Control (PCx) registers. The PCx registers are only on the TM4C129 series devices, and not on the TM4C123 series device you are using. Therefore, there is no need to call SysCtlPeripheralPowerOn().

[Note that even for the TM4C129 series devices SysCtlPeripheralPowerOn() is only supported on a sub-set of the peripherals, as documented in the TivaWare Peripheral Driver Library users's guide and device datasheets.]

The recommendation is to call Enable() followed, by Ready() in a loop to wait for the peripheral to be ready, as that matches the Programming Examples shown in the TivaWare Peripheral Driver Library users's guide. E.g.:

//
// Enable the GPIOA peripheral
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
//

// Wait for the GPIOA module to be ready.
//
while(!SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOA))
{
}

Hello Halo

Couple comments:

1) SysCtlPeripheralPresent isn't really needed unless you are planning to develop code across multiple TM4C devices which would have variance in the peripherals available. Very few times this is used.

2) You are right that the GPIOPinConfigure API is not needed for what you trying to do. It is used to configure a GPIO for specific peripherals like the ADC, Timer, UART, etc., it's basically for the GPIO muxing as a single pin will have many functions, but by default it will just be a standard GPIO so if you only need that, you don't need GPIOPinConfigure.

3) If you use GPIOPinTypeGPIOOutput then you don't need to call either GPIOPadConfigSet or GPIODirModeSet as those two calls are made by GPIOPinTypeGPIOOutput, so you have redundant code there, unless in the case of GPIOPadConfigSet, you want to change the push-pull settings, but you shouldn't need to in most cases.

The code should run as is though, it just can be improved.

Regarding the comment about peripheral clocks, that is correct but only for peripherals with clocks associated with them. GPIO pins do not have that. However, for an ADC for example, you would first Enable the ADC peripheral and the GPIO port that will be used with the ADC, then configure the GPIO (which doesn't have a clock), and then configure the ADC clock via the ADCClockConfigSet API (there are ClockConfigSet API's for all peripherals that need this step), and then lastly finish the rest of the ADC configuration. Hopefully this explains that portion of what the D/S was trying to communicate.