This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi,
I noticed, that if I use the pinmux Utility to generate the Init Code for PF0, the line for unlocking looked like this:
// Enable port PF0 for COMP0 C0O
// First open the lock and select the bits we want to modify in the GPIO commit register.
//
HWREG(GPIO_PORTF_BASE + GPIO_O_LOCK) = GPIO_LOCK_KEY_DD;
HWREG(GPIO_PORTF_BASE + GPIO_O_CR) = 0x1;
//
// Now modify the configuration of the pins that we unlocked.
//
MAP_GPIOPinConfigure(GPIO_PF0_C0O);
MAP_GPIOPinTypeComparator(GPIO_PORTF_BASE, GPIO_PIN_0);
This worked with the Stellarisware and the LM4F just fine.
Now I am trying to port this to a TIVA Controller TM4C123GH6PM.
The latest version of the Pinmux utility 1.0.2 already says Tiva C Series, but the code on this is unchanged.
Problem is, that the -DD Suffix seems unsupported now and generates a compiler error.
Taken from the current Tiva hw_gpio.h the value seems to match the old -DD value.
#define GPIO_LOCK_KEY 0x4C4F434B // Unlocks the GPIO_CR register
I have not had a chance to test the new hardware, and was wondering, if anyone has encountered any problems with this?
Possibly the pinmux utility needs a fix in that case?
Greetings,
Jan
Hi Jan,
Thank you for bringing this to our attention. This is a confirmed bug and is fixed in the next release.
That's a good get, Sir. That "GPIO_LOCK_KEY_DD" sprang from ye olde, "Dust Devil" (our group uses/used) and indeed shares the, "0x4C4F434B" you cite. (believe the Dust Devil was 1st to employ that Lock_Key encoding)
Our current LX4F's (not rebrand) .h file lists "GPIO_LOCK_KEY" correctly "0x4C4F434B" - freeing us from the archaic "DD" usage...
#define GPIO_LOCK_KEY 0x4C4F434B // Unlocks the GPIO_CR register