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.

Clock source configuration for GPIO PORT L on TM4C123GH6PGE controller

Issue facing:

When we try to write GPIO_PORTL_DIR_R, it is not writing and going to the Fault ISR.

Background details:

We have configured as follows.

// Clock power source config for 25Mhz
    SYSCTL_RCC_R = 0x00183E80;

// Clock source eneable for GPIO
    SYSCTL_RCGC2_R = 0X00000FFF;
    SYSCTL_RCGCGPIO_R = 0x0000FFFF;

During debugging, SYSCTL_RCGCGPIO_R shows 0x3F (R0 to R5 are set i.e Enable and provide a clock to GPIO PORT A to PORT F are only set).

Remaining Ports PORT G - PORT P are not provided with clock enable.

We understand if Enable and provide a clock to GPIO PORT L is set, then DIR register of PORT L can be written.

Kindly guide us early as possible to get the proper working condition.

thanks in advance.

Prabhu.N

  • Prabhu N said:
    Kindly guide us early as possible to get the proper working condition.

    Would not the standard, tested/proven TivaWare gpio functions more quickly/easily yield improved results?  And far less wear/tear upon vendor staff & humble outsiders.  (direct register forces much extra time/effort - and of course you want your answer, FAST!)

  • Hello Prabhu,

    If you have already intruded with the Debugger then it would be wise to check the SYSCTL_PPGPIO register first. The value present in the register will tell you how many GPIO ports are actually available.

    Also please note that using RCGCx and RCGCGPIO together has some limitations. The former exists for legacy software only and if you are doing first time development then use the latter "only".

    Regards

    Amit

  • Hi,

    thanks for your info.

    We removed the line     SYSCTL_RCGC2_R = 0X00000FFF; and tried.

    // Clock source eneable for GPIO
        SYSCTL_RCGCGPIO_R = 0x0000FFFF;

    SYSCTL_PPGPIO shows value 0x3F only. i.e PORT A to PORT F alone present. Remaining from PORT G are not present.

    We need to use PORT L. How to solve the issue ?

    Is there any possibility of having issue in hardware ?

    we tried with two numbers of controllers. the same observation.

    thanks,

    Prabhu.N

  • Hello Prabhu,

    Is the SYSCTL_PPGPIO shows that Port L is not present then it is a dead-end. You would have to change the TM4C device to a device which has Port L available.

    Please check the Product page t find which is the correct uC for the same

    Regards

    Amit

  • Hello Amit,

    The configuration (PORT L) was working previously in the same controller. 

    Now it is not working.

    this we can explain in detail over phone.

    could you please provide your contact number ?

    thanks,

    Prabhu.N

  • Hi Amit,

          We tested with the same code in an evaluation board(LX4F232H5QD).We are able to configure the clock

    source for all the ports and access it.Please find below the details of the controller used.Is there any change b/w

    the controller configuration

    Evaluation board                 --> 980 YF LX4F232H5QDF1GA3 2BAPQ9W G4

    Previously tested Board    --> 980 YF TM4C123GH6PGEI 3CA035W G4

    Currently testing Board      --> 980 YF TM4C123GH6PGEI 41AEPTW G4

     

    Thanks,

      ABINESH

  • Hello Abinesh,

    The two parts are identical in terms of the PPGPIO available. Are you sure you are reading the register at address 0x400FE308

    Also do read the word at 0x400FE004 and send me the data.

    Regards

    Amit

  • Hi Amit,

      We are able to program our target board now

    The issue was during parallel programming,our target board was not detected(Since ground reference was not given properly).

    Thanks for the support

    Thanks,

      ABINESH

  • abinesh kannan said:
    ... parallel programming our target board - ground reference was not detected

    Yet earlier (1st post) claim was, "When we try to write GPIO_PORTL_DIR_R, it is not writing and going to the Fault ISR."

    So - does the inconsistency between, "cure and earlier issue" not , "Jump out?"  (Port_L likely was not properly clocked/enabled due to (improper, complex) direct register usage!)

    Why only that port?    Surely many other ports - MCU features/functions would have been similarly impacted by, loss of ground...  Diagnosis (and/or initial report) very suspect...

    Unrewarded second post - this sequence - drilled down to the real issue...  (as all, "facts in evidence" herein suggest)

  • Hello cb1

    Even I am intrigued why only PORTL And also the original post suggests that it was repetitive failure.

    Abinesh,

    I think the forum would like to see you analysis on the same too with an explanation on why it occurred.

    Regards

    Amit

  • Amit Ashara said:
    Even I am intrigued why only PORTL

    My group thought, "Especially Amit" would be intrigued - thus I, "fell on the sword/took the bullet" so that a, "real explanation" could be offered.

    (although - in our hearts - you/I well know that "direct register" is demanding - requires great care/detail - and provides almost no benefit in set-up/config. of (most) general purpose registers.)