CCS/CC2640R2F: Set unused GPIO pins to PIN_UNASSIGNED for our smaller package, code downloads, but stays in infinite loop

Daniel Benkman

Part Number: CC2640R2F
Other Parts Discussed in Thread: TMP116, , BOOSTXL-BASSENSORS

Tool/software: Code Composer Studio

With your help, we have gone to the simple 'empty' project for our own board that uses a smaller CC2640R2 package. I changed the unused and out of range GPIO pins in CC2640R2_LAUNCHXL.h to PIN_UNASSIGNED. The pin-reduced 'empty' project code still runs on the TI SDK board, and it will now download to our board.

But instead of running normally on our board, it hangs forever in PIN_close(). The problem is that this code is in one of the optimized lower level files called PINCC26XX.c, so we can't display the variables.

It hangs in this PIN_close function forever with our smaller package, and does not hang there with the TI board that has the larger CC2640R2 package.

void PIN_close(PIN_Handle handle) {
uint32_t i;

// No need for sequencing accesses to PIN_close()
// For each pin in port bitmask

while (handle->portMask) {
// Find lowest index pin
i = PIN_ctz(handle->portMask);
// Deallocate pin
PIN_remove(handle, i);
}
}

Thanks for your continuing help. With your help, we are making progress, even if it's a bit slow and painful!

I will try moving the source code to our project as was suggested in an earlier question so that we can see what it's doing, but it seems that it simply shouldn't hang there in an infinite loop no matter what sized package it's running on.

Dan Benkman
Innowave

over 6 years ago

0 TER over 6 years ago

TI__Guru**** 317180 points

Could you first try to include the driver in the project enabling you to do a full debug/ step through?

Have you tried to step into Board_init(); to see if that causes any issues?

From where is the PIN_close() called, I could not see that this function is used when reading through the code.

0 Daniel Benkman over 6 years ago in reply to TER

Intellectual 525 points

As per your suggestion, I'm working on including the file in the project. There seems to be no absolute path to the file to be moved, and no absolute path to where the normal source files are located. I'm using Windows search over all of drive C to find both paths, so I can find exactly where the file is located, and exactly where to move it to.

I'm hoping that the moved file won't cause duplicates in its functions with the library code. We'll see soon.

I appreciate your help, and will mark the problems as closed when I can.

0 TER over 6 years ago in reply to Daniel Benkman

TI__Guru**** 317180 points

I guess I could have been clearer. In the project use "Add files...". This will add the driver file directly to the project, no need to worry about paths.

The drives could be found here: <SDK install path>\source\ti\drivers

0 Markel Robregado over 6 years ago in reply to TER

Guru 86745 points

Hi Daniel,

You said from your other post that you are using Empty RTOS project. It does nothing because it's empty and does not help much get through your objectives. I guess what you want to do is a BLE Temperature Monitoring device using TMP116.

To have BLE Peripheral Device, comment out all GPIO's at BoardGpioInitTable[] at CC2640R2_LAUNCHXL.c. Then rebuild all and flash hex file to your custom board using SmartRF Flash Programmer 2. It should work.

const PIN_Config BoardGpioInitTable[] = {

    //CC2640R2_LAUNCHXL_PIN_RLED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,       /* LED initially off */
    //CC2640R2_LAUNCHXL_PIN_GLED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX,       /* LED initially off */
    //CC2640R2_LAUNCHXL_PIN_BTN1 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS,          /* Button is active low */
    //CC2640R2_LAUNCHXL_PIN_BTN2 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS,          /* Button is active low */
    //CC2640R2_LAUNCHXL_SPI_FLASH_CS | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MIN,  /* External flash chip select */
    //CC2640R2_LAUNCHXL_UART_RX | PIN_INPUT_EN | PIN_PULLDOWN,                                              /* UART RX via debugger back channel */
    //CC2640R2_LAUNCHXL_UART_TX | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL,                        /* UART TX via debugger back channel */
    //CC2640R2_LAUNCHXL_SPI0_MOSI | PIN_INPUT_EN | PIN_PULLDOWN,                                            /* SPI master out - slave in */
    //CC2640R2_LAUNCHXL_SPI0_MISO | PIN_INPUT_EN | PIN_PULLDOWN,                                            /* SPI master in - slave out */
    //CC2640R2_LAUNCHXL_SPI0_CLK | PIN_INPUT_EN | PIN_PULLDOWN,                                             /* SPI clock */

    PIN_TERMINATE
};

After that modify the I2C pin out at CC2640R2_LAUNCHXL.h

/* I2C */
#define CC2640R2_LAUNCHXL_I2C0_SCL0             IOID_4
#define CC2640R2_LAUNCHXL_I2C0_SDA0             IOID_5

After that integrate the i2ctmp116 example program to Simple Peripheral.

But before doing all that I suggest you go through the Simplelink Academy to get some familiarization and know how.

http://dev.ti.com/tirex/explore/node?node=AO9tDQs88Bcw33.wxV2moA__krol.2c__LATEST

-kel

0 TER over 6 years ago in reply to Markel Robregado

TI__Guru**** 317180 points

On the other side, it's always good to get the smallest example up and running before going into the more complex stuff since it's much more easy to debug a small example.

0 Daniel Benkman over 6 years ago in reply to TER

Intellectual 525 points

I agree. I'll stick with the 'empty' project until I get it to download and run on our board. All we need after that is I2C and Bluetooth. I will code up everything else we need once those basic functions work with our smaller package chip and our board.

Moving the PINCC26XX.c file to the local project worked, but our board is at our office in Malaysia, and I'm temporarily back in Austin, Texas where I'm from. I have remote access when someone is in the office in Malaysia, but now it's 1:30 AM and time for bed here in the US.

Stepping through the code with the TI board I have here does not lead me to an instant understanding of all the code is trying to do in PIN_init(). It'll take me a while to figure out all the various structures involved and what they are trying to do, in order to see why it fails with our smaller chip.

An advantage of a massive and complex code base is that the user can make simple high level calls and get a lot done. But a disadvantage, when trying to do something different such as using a different processor package with a different board, is that problems can occur that require a lot of time and analysis of complex code that is not well commented to figure out the cause of the failure. That requires a whole new level of understanding of code that the customer theoretically doesn't need to deal with.

0 TER over 6 years ago in reply to Daniel Benkman

TI__Guru**** 317180 points

Could you give me some feedback when you have managed to debug a bit on the board?

0 Daniel Benkman over 6 years ago in reply to TER

Intellectual 525 points

I moved PINCC26XX.c and PINCC26XX.h to the local project, and they compile. However, it still hangs in this code:

void PIN_close(PIN_Handle handle) {
uint32_t i;

// No need for sequencing accesses to PIN_close()
// For each pin in port bitmask
while (handle->portMask) {
// Find lowest index pin
i = PIN_ctz(handle->portMask);
// Deallocate pin
PIN_remove(handle, i);
}
}

The 'i' variable always stays at zero, and it never leaves this loop.

I'm finding the code difficult to understand. PIN_init() uses several arrays and variables all related to GPIO pins, such as:

reservedPinMask
pinGpioConfigTable[]
pinConfigMask
PIN_ID(pinConfig[i])

#define PIN_ID(x) ((x)&0xFF) (Not sure what this means)
handle->portMask

It's not clear exactly what PIN_init() is trying to do here.

It may be that proper pin assignments for our reduced pin package chip would fix the problem, but it's a mystery on how to do that. The unused pins are already assigned to PIN_UNASSIGNED.

There should be something like this, below, at the 'user interface' level. If it's there, I definitely don't see it. Let's call it 'User_pindefs.h':

Simple example: Something like this should exist somewhere in the code, and it should be easy to find:

Pin_0 INPUT, PIN_PULLUP (unspecified options should go to defaults for the type of pin)
Pin_1 INPUT, PIN_NOPULL
Pin_2 OUTPUT, PIN_GPIO_HIGH, PIN_OPENDRAIN
Pin_3 PIN_UNSED

If such a file or table exists, I'm not sure where it is or what it's called. Can you point me to it?

If such a file does NOT exist, there should be a simple, step by step, detailed guide that shows the user exactly how to assign each pin the way he wants, even if it takes modifying 17 different structures in 12 files. Just walk the user through it, step by step in a document.

If there is such a document, I can't find it.

If we assign all the pins in our pin reduced chip, maybe the endless loop with i=0 problem will go away.

My boss said that if necessary, you can gain access to the laptop with our board connected to it with TeamViewer. That's what I've been doing, since I'm in the US and the board is in Kuala Lumpur.

I just found this table in CC2640R2_LAUNCHXL.c that seems to be something like what I'm talking about, but commenting it out does not fix the hang in PIN_close(). Besides, this table does not seem to define the pins, but only to 'alias' some names to others.

const PIN_Config BoardGpioInitTable[] = {

CC2640R2_LAUNCHXL_PIN_RLED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
CC2640R2_LAUNCHXL_PIN_GLED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
CC2640R2_LAUNCHXL_PIN_BTN1 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS, /* Button is active low */
CC2640R2_LAUNCHXL_PIN_BTN2 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS, /* Button is active low */
CC2640R2_LAUNCHXL_SPI_FLASH_CS | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MIN, /* External flash chip select */
CC2640R2_LAUNCHXL_UART_RX | PIN_INPUT_EN | PIN_PULLDOWN, /* UART RX via debugger back channel */
CC2640R2_LAUNCHXL_UART_TX | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL, /* UART TX via debugger back channel */
CC2640R2_LAUNCHXL_SPI0_MOSI | PIN_INPUT_EN | PIN_PULLDOWN, /* SPI master out - slave in */
CC2640R2_LAUNCHXL_SPI0_MISO | PIN_INPUT_EN | PIN_PULLDOWN, /* SPI master in - slave out */
CC2640R2_LAUNCHXL_SPI0_CLK | PIN_INPUT_EN | PIN_PULLDOWN, /* SPI clock */

PIN_TERMINATE
};

Thanks for your interest and help!

Dan

0 Markel Robregado over 6 years ago in reply to Daniel Benkman

Guru 86745 points

Hi Daniel,

I have worked with CC2640R2F 5x5 and 4x4, and I did not encounter your problem. It is just you need to do the proper procedure to make it work with the smaller CC2640R2F package. Reading through the documents will help a lot. As well as going through the Simplelink Academy.

Going back to your PIN_close(), hang problem, when and why did you call PIN_close(). Post your entire empty example program here for review.

Regarding, BoardGpioInitTable[] does your custom CC2640R2F board have all these below. If not comment it all out. Provide more details about your board such as I2C sensors, buttons, leds.

const PIN_Config BoardGpioInitTable[] = {

CC2640R2_LAUNCHXL_PIN_RLED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
CC2640R2_LAUNCHXL_PIN_GLED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
CC2640R2_LAUNCHXL_PIN_BTN1 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS, /* Button is active low */
CC2640R2_LAUNCHXL_PIN_BTN2 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS, /* Button is active low */
CC2640R2_LAUNCHXL_SPI_FLASH_CS | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MIN, /* External flash chip select */
CC2640R2_LAUNCHXL_UART_RX | PIN_INPUT_EN | PIN_PULLDOWN, /* UART RX via debugger back channel */
CC2640R2_LAUNCHXL_UART_TX | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL, /* UART TX via debugger back channel */
CC2640R2_LAUNCHXL_SPI0_MOSI | PIN_INPUT_EN | PIN_PULLDOWN, /* SPI master out - slave in */
CC2640R2_LAUNCHXL_SPI0_MISO | PIN_INPUT_EN | PIN_PULLDOWN, /* SPI master in - slave out */
CC2640R2_LAUNCHXL_SPI0_CLK | PIN_INPUT_EN | PIN_PULLDOWN, /* SPI clock */

PIN_TERMINATE
};

If your custom CC2640R2F board has I2C TMP116 then the i2ctmp116 CCS example program should work, you just need to modify the board files pinout. Then work with the i2ctmp116 CCS example program, and not the empty CCS TI-RTOS program.

-kel

0 Daniel Benkman over 6 years ago in reply to Markel Robregado

Intellectual 525 points

I did not call PIN_close(). The code called it by itself, I think from PIN_init(). I'm not sure why it called it.

I commented out the entire BoardGpioInitTable[]. It still gets stuck in the PIN_close() loop

0 Markel Robregado over 6 years ago in reply to Daniel Benkman

Guru 86745 points

Hi Daniel,

The I2C TMP116 CCS example program works for CC2640R2F Launchpad + BOOSTXL-BASSENSORS, I assume you have this working?

What does your CC2640R2F Custom Board has I2C TMP116 and what else. What pins is the I2C TMP116 connected to the CC2640R2F?

Use the i2ctmp116 ccs example program for testing. Do this below

1. At CC2640R2F_LAUNCHXL.h change I2C Pinout where the I2C TMP116 connected to the CC2640R2F.

/* I2C */
#define CC2640R2_LAUNCHXL_I2C0_SCL0 IOID_4
#define CC2640R2_LAUNCHXL_I2C0_SDA0 IOID_5

2. At CC2640R2F_LAUNCHXL.c comment out all the Pins at BoardGpioInitTable[].

const PIN_Config BoardGpioInitTable[] = {

//CC2640R2_LAUNCHXL_PIN_RLED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
//CC2640R2_LAUNCHXL_PIN_GLED | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
//CC2640R2_LAUNCHXL_PIN_BTN1 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS, /* Button is active low */
//CC2640R2_LAUNCHXL_PIN_BTN2 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_BOTHEDGES | PIN_HYSTERESIS, /* Button is active low */
//CC2640R2_LAUNCHXL_SPI_FLASH_CS | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MIN, /* External flash chip select */
//CC2640R2_LAUNCHXL_UART_RX | PIN_INPUT_EN | PIN_PULLDOWN, /* UART RX via debugger back channel */
//CC2640R2_LAUNCHXL_UART_TX | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL, /* UART TX via debugger back channel */
//CC2640R2_LAUNCHXL_SPI0_MOSI | PIN_INPUT_EN | PIN_PULLDOWN, /* SPI master out - slave in */
//CC2640R2_LAUNCHXL_SPI0_MISO | PIN_INPUT_EN | PIN_PULLDOWN, /* SPI master in - slave out */
//CC2640R2_LAUNCHXL_SPI0_CLK | PIN_INPUT_EN | PIN_PULLDOWN, /* SPI clock */

PIN_TERMINATE
};

Then see, if you still encounter the PIN_close() hang issue. I assume that before you have successfully debug your board that is in Malaysia.

-kel

0 Daniel Benkman over 6 years ago in reply to Markel Robregado

Intellectual 525 points

OK, I traced how it gets to PIN_close(). The quick path:

int main(void) > Board_init() > Board_initHook() > CC2640R2_LAUNCHXL_shutDownExtFlash() > PIN_close(extFlashPinHandle)

CC2640R2_LAUNCHXL_shutDownExtFlash() has GPIO20 hard coded, and the chip only has 15 GPIOs. It causes PIN_close to hang in an infinite loop

The complete path is below

You can see below that IOID_20 is specifically used in lines 91, 104, and 107 of CC2640R2_LAUNCHXL_wakeUpExtFlash() in CC2640R2_LAUNCHXL_fxns.c

The smaller chip is limited to GPIOs 0 - 14. GPIO 20 does not exist.

You guys should come up with a fix. IOID_20 should either be symbolically redefined somehow, or disabled for the smaller chip package. It seems like TI should fix this, not a customer.

Please advise on how to fix this. If it will take TI a while to make a 'proper fix', can you come up with a suggestion?

Code in main_tirtos.c:
int main(void)
Board_init(); Line 64 of main_tirtos.c
void CC2640R2_LAUNCHXL_initGeneral(void) Line 1029 of CC2640R2_LAUNCHXL.c
If (PIN_init()...) Line 1033 of CC2640R2_LAUNCHXL.c
Board_initHook(); Line 1039 of CC2640R2_LAUNCHXL.c

CC2640R2_LAUNCHXL_fxns.c:
Exact code in CC2640R2_LAUNCHXL_fxns.c:

Line#
153 void Board_initHook()
154 {
155 CC2640R2_LAUNCHXL_shutDownExtFlash();
166 }

117 void CC2640R2_LAUNCHXL_shutDownExtFlash(void)
118 {
119 /*
120 * To be sure we are putting the flash into sleep and not waking it,
121` * we first have to make a wake up call
122 */
123 CC2640R2_LAUNCHXL_wakeUpExtFlash();

87 void CC2640R2_LAUNCHXL_wakeUpExtFlash(void)
88 {
89 PIN_Config extFlashPinTable[] = {
90 /* SPI Flash CS */
91 IOID_20 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | <-- illegal GPIO for small package
92 PIN_INPUT_DIS | PIN_DRVSTR_MED,
93 PIN_TERMINATE
94 };
95 PIN_State extFlashPinState;
96 PIN_Handle extFlashPinHandle = PIN_open(&extFlashPinState, extFlashPinTable);
97
98 /*
99 * To wake up we need to toggle the chip select at
100 * least 20 ns and ten wait at least 35 us.
101 */
102
103 /* Toggle chip select for ~20ns to wake ext. flash */
104 PIN_setOutputValue(extFlashPinHandle, IOID_20, 0); <-- illegal GPIO for small package
105 /* 3 cycles per loop: 1 loop @ 48 Mhz ~= 62 ns */
106 CPUdelay(1);
107 PIN_setOutputValue(extFlashPinHandle, IOID_20, 1); <-- illegal GPIO for small package
108 /* 3 cycles per loop: 560 loops @ 48 Mhz ~= 35 us */
109 CPUdelay(560);
110
111 PIN_close(extFlashPinHandle); <-- Hangs in this function forever
112 }

0 TER over 6 years ago in reply to Daniel Benkman

TI__Guru**** 317180 points

A board file is a file that is written to reflect the given hardware the software is running on. From TI side we are providing boardfiles for the launchpads (typically) and the file will therefore reflex this hardware. Since custom hardware can use a large amount of different IO configurations we can't provide board files that are correct for everyone.

Do you have an external flash on your board? If no, you can just remove the call to this function. If yes, you need to change the function to use whichever IOs you use on your board.

0 Daniel Benkman over 6 years ago in reply to TER

Intellectual 525 points

We don't have external flash, so I just commented it out. The hang no longer exists, and our chip runs the code to turn the LED on and off. Of course, we don't have an LED on or board, and I can't look at the pin with a scope from here.

In the empty.c code that lights the LED, the name 'Board_GPIO_LED0' is used. It is defined as '5' in an enum, but the board schematic says that is is on GPIO6. Is there some additional mapping that converts that '5' to a '6'?

0 Markel Robregado over 6 years ago in reply to Daniel Benkman

Guru 86745 points

Hi,

Seems that reflects the gpioPinConfigs[] at CC2640R2F_LAUNCHXL.c. Anyway, since your done trying out the empty example program, I suggest focus next on what is on your custom board.

/*
* Array of Pin configurations
* NOTE: The order of the pin configurations must coincide with what was
* defined in CC2640R2_LAUNCHXL.h
* NOTE: Pins not used for interrupts should be placed at the end of the
* array. Callback entries can be omitted from callbacks array to
* reduce memory usage.
*/
GPIO_PinConfig gpioPinConfigs[] = {
/* Input pins */
GPIOCC26XX_DIO_13 | GPIO_DO_NOT_CONFIG, /* Button 0 */
GPIOCC26XX_DIO_14 | GPIO_DO_NOT_CONFIG, /* Button 1 */

GPIOCC26XX_DIO_15 | GPIO_DO_NOT_CONFIG, /* CC2640R2_LAUNCHXL_SPI_MASTER_READY */
GPIOCC26XX_DIO_21 | GPIO_DO_NOT_CONFIG, /* CC2640R2_LAUNCHXL_SPI_SLAVE_READY */

/* Output pins */
GPIOCC26XX_DIO_07 | GPIO_DO_NOT_CONFIG, /* Green LED */
GPIOCC26XX_DIO_06 | GPIO_DO_NOT_CONFIG, /* Red LED */
GPIOCC26XX_DIO_30 | GPIO_DO_NOT_CONFIG, /* TMP116_EN */

/* SPI Flash CSN */
GPIOCC26XX_DIO_20 | GPIO_DO_NOT_CONFIG,

/* SD CS */
GPIOCC26XX_DIO_21 | GPIO_DO_NOT_CONFIG,

/* Sharp Display - GPIO configurations will be done in the Display files */
GPIOCC26XX_DIO_24 | GPIO_DO_NOT_CONFIG, /* SPI chip select */
GPIOCC26XX_DIO_22 | GPIO_DO_NOT_CONFIG, /* LCD power control */
GPIOCC26XX_DIO_23 | GPIO_DO_NOT_CONFIG, /*LCD enable */

};

0 Daniel Benkman over 6 years ago in reply to Markel Robregado

Intellectual 525 points

From Empty.c:

/* Turn on user LED */
GPIO_write(Board_GPIO_LED0, Board_GPIO_LED_ON);

while (1) {
sleep(time);
GPIO_toggle(Board_GPIO_LED0);
}

From line 91 of Board.h:
#define Board_GPIO_LED0 CC2640R2_LAUNCHXL_GPIO_LED_RED

From line 303 of CC2640R2_LAUNCHXL.h, copied below:

If you put your mouse over CC2640R2_LAUNCHXL_GPIO_LED_RED on line 313 it says '5', not 6. It is also entry #6 in the enum, but it starts at entry #0. Both the position in the enum, and hovering the mouse over line 313 says the value is 5.

In the line you showed above, GPIOCC26XX_DIO_06 | GPIO_DO_NOT_CONFIG, /* Red LED */ Red LED is a comment, and it's not even the same name. How does that comment change a 5 to a 6?

303 /*!
304 * @def CC2640R2_LAUNCHXL_GPIOName
305 * @brief Enum of GPIO names
306 */
307 typedef enum CC2640R2_LAUNCHXL_GPIOName {
308 CC2640R2_LAUNCHXL_GPIO_S1 = 0,
309 CC2640R2_LAUNCHXL_GPIO_S2,
310 CC2640R2_LAUNCHXL_SPI_MASTER_READY,
311 CC2640R2_LAUNCHXL_SPI_SLAVE_READY,
312 CC2640R2_LAUNCHXL_GPIO_LED_GREEN,
313 CC2640R2_LAUNCHXL_GPIO_LED_RED,
314 CC2640R2_LAUNCHXL_GPIO_TMP116_EN,
315 CC2640R2_LAUNCHXL_GPIO_SPI_FLASH_CS,
316 CC2640R2_LAUNCHXL_SDSPI_CS,
317 CC2640R2_LAUNCHXL_GPIO_LCD_CS,
318 CC2640R2_LAUNCHXL_GPIO_LCD_POWER,
319 CC2640R2_LAUNCHXL_GPIO_LCD_ENABLE,
320 CC2640R2_LAUNCHXL_GPIOCOUNT
321 } CC2640R2_LAUNCHXL_GPIOName;

0 Daniel Benkman over 6 years ago in reply to Daniel Benkman

Intellectual 525 points

I figured it out.

enum CC2640R2_LAUNCHXL_GPIOName in CC2640R2_LAUNCHXL.h assigns a number to the name of the function connected to a GPIO.

In the case of the pin function called CC2640R2_LAUNCHXL_GPIO_LED_RED, it is the 5th entry in the enum array. That means that CC2640R2_LAUNCHXL_GPIO_LED_RED is assigned a numeric value of 5.

That value (5 in this case) accesses the 5th entry in a table called GPIO_PinConfig gpioPinConfigs[] in CC2640R2_LAUNCHXL.c. The 5th entry (with zero being the first entry) in this table turns out to be

GPIOCC26XX_DIO_06 | GPIO_DO_NOT_CONFIG, /* Red LED */.

Therefore, the '5' ends up accessing GPIO 6.

In summary:

Pin function (such as LED_Red or SPI_MASTER_READY) ---> Number from enum array in CC2640R2_LAUNCHXL.h ---> offset into GPIO_PinConfig gpioPinConfigs[] in CC2640R2_LAUNCHXL.c ---> GPIO number

Bluetooth®︎

Bluetooth forum

CCS/CC2640R2F: Set unused GPIO pins to PIN_UNASSIGNED for our smaller package, code downloads, but stays in infinite loop