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.

TM4C1230H6PM: GPIOG is not present

Part Number: TM4C1230H6PM


It's been long time, so hello to everyone!

I'm in the developers state of a self made board, and so far all went fine.

On the board there are two RS485 ports, connected to respectively UART0 and UART2, on the GPIO ports A & G

So far, I've only coded for the first port, UART0 on port A, and all is working fine. Now I added code for the second port, UART2 on port G, and right away it goes into FaultISR.

Hum, I'm sure I enabled all clocks and peripherals needed, what's happening?

So after some debugging I look into the SYSCTL register and check the device capabilities, and in register PPGPIO I see that GPIOG is not present, it surely should be!

I checked the part on my board, and it is a TM4C1230H6PM, so it should have a port G...

Any suggestions?

  • Hello Marc,

    That device definitely has GPIOG present.

    Can you post the following:

    1) Screenshot of the register in CCS

    2) Your code to configure UART2 and the pins on Port G

  • Greetings,

    Is it possible that your IDE has not 'fully/properly' identified your "TM4C1230H6PM" as the device selected?     My group uses the 'plain jane' TM4C123 - which does not support Port G.

    We use IAR - but it would be useful for you to 'deliberately' disable (by not enabling) another of your 'known' MCU Ports - and then checking to see if such 'disabling' proves sufficient to 'Remove that (disabled) Port from residence w/in Register  'PPGPIO.'     Should Register 'PPGPIO' (continue) to recognize the 'just disabled' Port - then it is likely that (somehow) the IDE has not 'locked onto' your chosen MCU.

    Tag:  When an MCU Port - 'goes missing.'

  • cb1_mobile,

    I use uVison from Keil, and the part is definitely defined correctly.

    Isn’t the ‘PPGPIO’ just a read-only register, which is read from the core processor? 

    What I mean is that even if I would define the wrong part for the compiler, it would (maybe) get me some compiler errors, but the ‘PPGPIO’ register would still represent the ‘correct’ configuration data from the part when debugging.

  • Hello Marc,

    While not terribly familiar with Keil, yes I believe you are right if it shows up in the view as PPGPIO is a register that exists on all TM4C123 devices, so the contents that are read out would not be checked the expected results for the defined part number. As far as I know when debugging, the part number is more to define what registers are available at what locations etc. and not how many valid bits there are or to check for correct data being present based on the D/S.

    I would only be concerned about the part number if the register might not exist for specific parts.

  • Hello Ralph,

    Yes that's what the part define basically is for, to define specific pin names and bit masks used by the Tivaware lib. Using the wrong part definition will more likely give a compiler error, using a pin or peripheral definition which was not defined.

    I guess I've a wrong/broken part; I looked in the datasheet for the PPGPIO reset value, normally it should be 0x0000.007F, mine is 0x0000.003F. I then also looked at the device identification(DID0-DID1), and what I found out is that I have a engineering sample (bits1..0 = 0 in register DID1)...

    Strange because I've bought those chips from Digikey, not from the grey market...

  • Hello Marc,

    That is very strange that you got an engineering sample. You can probably ask them to look up the lot number and find the date for the device that way. Maybe they weren't aware they had let such old material slip through the cracks. Sorry you had that issue.

    Not sure how many you need, but you can also order some free samples through the TI eStore:

    I'll go ahead and close this thread since the issue seems to be that you got an engineering sample.

  • Just to quickly & kindly 'Beat this dead horse 'One last time' - might you disable a 'known good MCU Port' - and then observe, 'If & How that 'disabling' shows up in the PPGPIO Register?'

    My firm past used 'hundreds' of 'LX4F23x MCUs' (no official LM4F devices were ever issued to the public) - yet the 'X' indicated pre-production (perhaps even engineering sample) and ALL Ports promised - WERE DELIVERED!   (as I recall - certain LX4F devices suffered a 'Reset Sensitivity - which (never) impacted my firm.)

    Again we use (and have used) IAR - is it not useful to 'alter your IDE's 'MCU Selection Choice'  (to the  Port_G-LESS  TM4C123)  - and then observe the Registers which  PPGPIO claims to be 'present?'     Seems a quick/dirty & eased test - does it not?

    Tag: Poster's Kingdom in exchange for a functional Port_G...