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.

About Port pin multiplexing in TM4C1233H6PM

Other Parts Discussed in Thread: TM4C123GH6PM, TM4C1233H6PM

Port A2 : SSIOCLK  by default

I want to configure this pin to GPIO in output mode.

Code which i have used

 SYSCTL_RCGC2_R |= 0x00000001;     // activate clock for Port A

  SysCtlDelay(1000);      // allow time for clock to start

  GPIO_PORTA_AMSEL_R &= ~0x04;      // disable analog on PA2

  GPIO_PORTA_PCTL_R &= ~0x00000F00; //  PCTL GPIO on PA2

  GPIO_PORTA_DIR_R |= 0x04;         // PA2 out

  GPIO_PORTA_AFSEL_R &= ~0x04;     // disable alt funct on PA2

  GPIO_PORTA_DEN_R |= 0x04;   //digital enable

GPIO_PORTA_DATA_R &= ~(0x04);  // Zero on PA2

though  i made PA2 low ,  it shows Continuosly high voltage.

Anyone knows what is wrong in my code.

  • Hello Geetesh,

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, 0xff);
    GPIOPinWrite(GPIO_PORTA_BASE, 0xff, 0x00);

    The above codes will easily work out for you. Avoid direct register addressing. (As per instructions by former members)

    Regards

    Vikram

  • Thanks for quick reply Vikram.

    I already  tried this code but it does not  work.
    Pin voltage is constant  ~2.4 Volts.

    Why we can't use  Direct registers configuration ?

  • I'll suggest, take project0 from the TivaWare. Paste the code above while loop. It works well. I checked. :)
    Regarding Direct Register Configuration you can expect reply from other members.
    Regards
    Vikram
  •  Hi Vikram, original poster wanted just PA2 output and go low so 0xff has to be changed to 0x04 or better with a simbolic like GPIO_PIN_2 or user assignes for clarity.

     

    Vikram Dewangan said:

    GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, 0xff);

    GPIOPinWrite(GPIO_PORTA_BASE, 0xff, 0x00);

  • GEETESH SINGH said:
    I already  tried this code but it does not  work.

     Your code as from suggested has same problem and I bet if you debug your code is catched on ISR Fault too, maybe we can add something more on first sticky too. After enabling peripheral some clock cycles are needed before to use otherwise it doesn't work. So add proper delay before to set output and also your code work too.

    http://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/374640

     in this reference issue #2 refer to your code problem and suggested too with same problem. Problem has to be understood in deep otherwise get again to light unexpected.

     I suggest read all first sticky to learn about frequently trap and how to solve.

    GEETESH SINGH said:
    Why we can't use  Direct registers configuration ?

     You can use direct register but code is more difficult to debug, if you are not a beginner then you can benefict slight timing improvement but again is hard to mantain code and you need hi level of attention to trap what is wrong.

     As you see still using API not many grasped what is really wrong.

     Add magic delay or better check for peripheral ready flag then  both version of code got to light than hells of silent hardware fault. (read first sticky about ISR fault)

  • Sir, i cant understand meaning of "take project0 from Tivaware" ??
    i also tried the below code:

    #include <stdint.h>
    #include <stdbool.h>
    #include "inc/tm4c123gh6pm.h"
    #include "inc/hw_types.h"
    #include "inc/hw_memmap.h"
    #include "inc/hw_gpio.h"
    #include "driverlib/sysctl.h"
    #include "driverlib/pin_map.h"
    #include "driverlib/gpio.h"
    #include "driverlib/rom_map.h"


    int main()
    {

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    SysCtlDelay(2051); // 416 microsec
    GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE,GPIO_PIN_2);

    while(1)
    {
    GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_2, 0x04);
    SysCtlDelay(1000000);
    GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_2, 0x00);
    SysCtlDelay(1000000);
    }

    }

    i am using keil microvision 5 IDE and in peripherals it shows the correct output but in hardware kit it can't . But i think keil 5 IDE not showing the correct output in peripherals because when i check the same code for PORTF.0 (by proper change in GPIO_PORTX_BASE, GPIO_PIN_X, 0xXX) it still shows the inverting output which is i think wrong .
    because PORTF.0 is NMI pin and it is locked . We have to unlock the pin before we use this pin as GPIO (as per TM4c1233H6PM datasheet).
    SIr whether u have checked ouptut on Hardware (evaluation or development board).
    Thank you.
  • sir i have checked :
    while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOA)))
    {
    }
    but my code stucks into while loop .. dont know why ???
    i also tried different delays ...
    plz suggest what is wrong in my code ....

    my complete code is as:

    #include <stdint.h>
    #include <stdbool.h>
    #include "inc/tm4c123gh6pm.h"
    #include "inc/hw_types.h"
    #include "inc/hw_memmap.h"
    #include "inc/hw_gpio.h"
    #include "driverlib/sysctl.h"
    #include "driverlib/pin_map.h"
    #include "driverlib/gpio.h"
    #include "driverlib/rom_map.h"


    int main()
    {

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    while(!(SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOA)))
    {
    }

    GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE,GPIO_PIN_2);

    while(1)
    {
    GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_2, 0x04);
    SysCtlDelay(1000000);
    GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_2, 0x00);
    SysCtlDelay(1000000);
    }

    }
  • First off - your reported "measure" of 2V4 has been missed by (all) others.  That value sounds my alarm - indicates that your port/pin is (still) in input mode - or that your board's power voltage is not @ proper 3V3.  Have you measured for 3V3 from your Voltage regulator - to each/every MCU Vdd pin?

    If that 3V3 is correct - may I suggest this - broader, full port approach - which escapes any "single pin/bit irregularity?"

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    SysCtlDelay(1000000);  //  I've eliminated the peripheral ready function which you report to, "hang!"
      
    GPIOPinTypeGPIOOutput(GPIO_PORTA_BASE, 0xFF);  // Let's expand and test the entire Port (eliminates single pin anomaly)

    while(1)
      {
          GPIOPinWrite(GPIO_PORTA_BASE, 0xFF, 0xFF);  // Sets every bit - Port A
          SysCtlDelay(1000000);
         GPIOPinWrite(GPIO_PORTA_BASE, 0xFF, 0x00);  // Clears every bit - Port A
         SysCtlDelay(1000000); 
      }

    You're silent as to past history - your board.  What (cruel) events occurred?

    In the unlikely event Port A does not respond - switch to Port B or another Port (but not Port C) and test & report.

    Final point - is it possible that your code never really runs - that you jump quickly into Fault ISR - and all of our programming guidance is thus in vain?

    And - we're not told "How you measure that 2V4."  That reading itself is suspect - may indicate that the pin is in input mode.  (i.e. has never been programmed away from power-up setting!)   Is your (we guess) DMM tied to power ground - and are you (surely/really) connecting to a Port pin not, "blessed" with dreaded 0-ohm resistors?  (which continue to torment all here - long after this horrid design decision has long been proven inept/ill chosen - of NO (real) value!)

  • cb1- said:

    Final point - is it possible that your code never really runs

    Well explained cb1. Taking a working project like blinky/project0 and checking if the code is running (or simple change in code like blink delay is reflecting in the board) would be a nice start. Than later add the desired code one by one to validate the functionality.

  • Thank you, Vikram. Note too that I "broadened" poster's test code too - so that he may test 8 bits w/each pass - not just a (potentially deceased) single pin!

    KISS always works best - fastest - and his start w/Direct Register breaks strongly from that guidance. (and pity that "blinky" - in its desire to minimize "includes" - employs Direct Register!) Oh well - engineering/programming is not w/out trade-offs - and the quest for the "basics" and simplicity (i.e. KISS) remains our standard... (and enables our doors to remain open - and product to ship...)
  •  H

    cb1- said:
    And - we're not told "How you measure that 2V4."  That reading itself is suspect - may indicate that the pin is in input mode.  (i.e. has never been programmed away from power-up setting!)   Is your (we guess) DMM tied to power ground - and are you (surely/really)

     Hi CB1, I apologize I suddenly forgot that pain.. also recent one remembered day elapsed into oblivion.... so R9 R10 belong to port B and port D issue, but I also remember a dead Port A pin, too much rime elapsed and oblivion got it away. This was at almost 2 year ago, LMX120 got warm not hot but pin remained unusable, issue just started at 2V4 then dropped down to near 1V and I just moved pin to another location, setting as input no problem as output case became hot in a short while.

    TOMB STONED on TIVA

     and

    OLD STELLARIS AGE

    STACK DOUBLE SETTING pain

     CCS VERSIONING AND first attempt porting from Stellaris to new TIVA

    And at last

     M$ CCS ISSUE, still in place too but now Linux version is fine and few issue remain to be fixed, may be next release I can finally decide buy a licence?

  • GEETESH SINGH said:
    plz suggest what is wrong in my code ....

     I am not sure this is complete code, anyway to do that I need some magic art I assure you I can use to assure good life myself before to search error in code.

     Getting an eye to your code we need understand if code get to fault ISR, from your writing loop forever waiting peripheral ready, in this case I can try hypotheses of clock setting is missing or Port A faulty..

     Add clock initialization code if not in place,

     after peripheral get ready

    see if pin work, if not  try another pin to see if it work.

    GEETESH SINGH said:
    GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_2, 0x04);

    GPIOPinWrite(GPIO_PORTA_BASE, GPIO_PIN_2, GPIO_PIN_2);

     D not intermix simbolic and numeric, or better assign a preprocessor label.

     

  • Roberto,

    You've never (ever) any need to apologize - your heart is BIG - and GOOD - you help so many. (this reporter, included)

    We've yet to KILL an ARM MCU pin (but for one - on LM3S16xx - and I don't know how) but his 2V4 signals something is not right! And great that you steered him (fast/far) from Direct Register - API is free - fast and tested - Direct Register (NONE of the above!)

    I did not think Port A was impacted by the "high IQ" decision process to "SHORT MCU pins." (surely better minds than you/I...)

    My directing him to toggle the ENTIRE PORT - rather than Single Pin - is a SPEED UP TRICK my group often employs. He may well have KILLED one port pin - the ENTIRE PORT - unlikely!

    Ciao,
  • In my case no short where in place nor troubles, I think an ESD was primary issue and never appened again.. So as primary rule "Tomb Stoning" resistor is the first rule! This way remember me and other forever to REMOVE THEM BEFORE TO POWER UP!!
  • i got the correct output on these pins only
    PA1 : U0TX (default)
    PA3 : SSIOFss (default)
    PA6
    PA7
    but i want output on PA2 (SSIOCLK) which shows constant DC voltage ....
  • Hello Geetesh,

    Please share the updated code and waveform plots?

    Regards
    Amit
  • Hi Geetesh, you wrote:
    >> but i want output on PA2 (SSIOCLK) which shows constant DC voltage ....
    Are you measuring this by a scope or a multimeter? So is this real voltage or AVG of a running waveform-? What happen to voltage on pin when you press reset button?
  • Hi Amit,

    Waveform plots - from poster's DMM - may not be, "in the cards."

    Note that w/the suggestion to toggle ALL of Port A's pins - some do appear to toggle/respond.

    Even under my direct examination - poster remains unresponsive to, "What did you past do to kill PA2?"  (I was bit kinder in the courtroom)

    As you/I know - many/most MCUs here have Port A "defaulting" into special, serial modes.  Thus - is it sufficient to employ GPIOPinType() to "re-purpose" those Port A pins into GPIO Output mode?  (believe both your & my response illustrated - although I ordered the entire port into output - and (then) toggled each/every Port A pin...

  • GEETESH SINGH said:
    i(sic) I got the correct output on these pins only: PA: 1,3,6,7...

    Does your board connect to another - or have you modified it (assume launchpad) in any way?

    And - have you past connected other boards, components, to Port A?   That's important as its highly unusual for the Port to "fractionally respond" unless you butchered the code block I provided.   (which toggled the entire Port)

    Is your board new - or acquired from another - or a school board - with both "uncertain and past" use? 

    As you claim to achieve "correct output" on 4 of Port A pins - might you share your definition of "correct output?"

    And - Roberto's suggestion of monitoring PA2 (and failing others) while you hold the reset button - is inspired - what happens then?