TM4C123GH6PM: TM4C123GH6PM as I2C Slave

Might your read/review of the "Peripheral Driver Library User Guide - I2C Section" along w/the MCU Manual (same section) - reduce the "terror" of your quest?     Any "quick/dirty" - Cookbook Copy/Paste - will NOT serve your interests well - long term.     Understanding proves key - and the challenge of proper & detailed "Set-Up" - is not one you should avoid...   (such will create REAL TERROR!)

Use of the Forum's Search Box (atop the forum page) key-worded "I2C Slave" should yield many past posts from users seeking quite similar capability.

The choice of (both) I2C Master & I2C Slave - employed to "communicate" - adds a "high hurdle" to your objective. (i.e. Should communication "fail" - how will you know if the offender is: Master, Slave or both?) Initiating a (likely) first project - with this level of complexity - is a sure violation of "KISS" - which always argues for simplicity - and "proceeding (systematically) by refinement."

A "KISS" compliant method would see you employ just one MCU - configured as Master - and connected to a simple, small capacity, I2C based EEProm. (and even that - orders of magnitude easier than that which you've proposed - may challenge)

Mountain climbers (rarely) climb the "highest mountain" as "first climb." (at least those who "live to tell the tale" of that (first) climb...) Perhaps a "lesson" lies w/in their choice of "easier" hills as "starters."

like you said, (Mountain climbers (rarely) climb the "highest mountain" as "first climb.") 

Could be my first post in this forum but lets say that this is not my "first climb",  i've  been working with I2C while ago with TM4C123GH6PM as master with no issues, but now i want to challenge myself a little bit setting up my  TM4C123GH6PM as Slave.

I dont like to use the "Peripheral Driver Library" because, this library only helps you to send and receive data, but does not show you how I2C works.

I prefer to create my own functions and set it up as Slave Mode step by step writing and reading directly from the registers.

Terror55 said:

I dont like to use the "Peripheral Driver Library" because, this library only helps you to send and receive data, but does not show you how I2C works.

That's surely your right - yet the "capability, extent, & power" of vendor's API has both, "far more quickly propelled & insured the success" of thousands of user-clients.

Note that the API is "Tried, True, Trusted!"    (i.e. has been in use long enough that "most of the gremlins" have been noted - & banished.)      None of those (important three "Ts") will result from "user re-invention" - at least not w/in the "reasonable" short term.

You claim, "does not show...how I2C works."    Yet - nothing prevents you from a "Line by line, Register by register" (i.e. deep-dive) into the API's source code.    In counter - I believe that "everything regarding "I2C's working" stands naked - and revealed - by the API.    (especially for those - like yourself - who care to, "probe & look under the hood.")

You're of course free to "create your own functions" - especially where/when the API has "gaps" (my firm has done just that) yet that effort is best implemented as an ADDITION to the API - not an (almost) needless (and risky)  - full replacement.   

The tech world - as you surely know - is highly global and firms today, "race to develop compelling solutions."     Those arriving first (at minimum early) to market fare best.   (i.e. profit margins are highest)    Those "rolling their own - too often arrive "late" - to vastly shrunken profit and unsettling firm morale!      

My small firm works in/around the nexus of tech & finance - daily we are reminded that, "Time is of the Essence!"    

Vendor's well conceived API, "Speeds, Eases, Enhances" such development - other choices - "Not so much!"     (investors are famed for then asking,  "And for what?" ... ... as they flee...)