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.

Can't set Bit 7 in GPIO_PORTD AFSEL register in TM4C1294 microcontroller

I want to set the bit 7 in PORTD AFSEL register to use the PD7 pin as SSI2XDAT2 peripheral but it seems that the microcontroller does not change it.

The following code does not change the bit.

HWREG(GPIO_PORTD_BASE + GPIO_O_AFSEL) |= GPIO_PIN_7; or (*((volatile uint32_t *)(0x40007420))) |= 0x80;

I also tried HWREG(GPIO_PORTD_AHB_BASE + GPIO_O_AFSEL) |= GPIO_PIN_7; or (*((volatile uint32_t *)(0x4005B420))) |= 0x80;

I've tried different approaches (using the tiva library, etc.) but it isn't working.

Furthermore, I've tried to change the bit using the debugger and I can't change it. (I can change every other bit)

This is an errata I've missed? Please help.

  • Hello Fabian,

    Please have a look a the Issue#1 mentioned in the following post. Pin PD7 is a locked pin and requires a specific procedure to unlock.

    e2e.ti.com/.../374640
  • PD7 and (partner in crime) PF0 continue (UNABATED) their joint torment of vendor clients!

    WHEN will this (ever) end?   

    Is client pain/suffering insufficient to BUDGE vendor's (ineffectual) response?

    Does this fully/properly convey vendor's (assumed) care/concern for SO MANY?   Should it?

  • Thank you very much!

    I missed that in the datasheet.

    You saved me a lot of work time.

  • Hello Fabian

    As cb1 very well stated, there needs to be a better way of putting out this information, and the trouble we have faced is a datasheet update may still not guarantee the easy miss in the data sheet. That is why we went ahead and created a Sticky Post....
  • Yet - unfortunately - "How can the new user be expected to: Find, then effectively read/absorb - such fine detail?"

    Issue has persisted for years - few B-Schools teach, "Avoid Corrective action - for as long as possible!" Or employ a series of, "Ineffectual Band-Aids!"

    A similar "breach" of User Comfort/Convenience notably appears w/in the (delightful) "Plague-Istors" which "dead-short" 2 pairs of MCU pins - and which is noted (in mice type) upon a "busy" schematic.   This appears upon an otherwise excellent 4C123 LPad.  (possibly others, as well)

    NO Vendor achieves PERFECTION - yet allowing (welcoming?) KNOWN ISSUES TO PERSIST - TO FESTER - makes NO SENSE!

    As one here among the longest - and earlier upon predecessor LMI Forum - it is painful to see VERY WELL KNOWN ISSUES continue!