• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 1160 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

EK-TM4C123GXL: I2C MTR register can't be written

Igor Misic
Prodigy 50 points

Part Number: EK-TM4C123GXL
Other Parts Discussed in Thread: TM4C123GH6PM

Hi guys, please check this. I am trying to put some data inside MDR register but value inside MDR stays 0x00? Did I miss something? Value of important registers are on picture. 

I am fallowing chapter 16.4.1 from TM4C123GH6PM datasheet.

 




  • 0
    Guru 117855 points

    Igor Misic said:
    Did I miss something?

    Vendor has an extensive API - which exhaustively details the "care/handling" of (all things) I2C.     And - spectacularly, "Speeds, Eases, Enhances" your (and others') programming efforts.

    Use of  "Direct Register Manipulation" - as you present - adds great complexity - is (sometimes) claimed to, "increase understanding" - but (instead) causes delay, frustration - and LITTLE UNDERSTANDING!

    If you are being "forced" to employ (only) such,  "archaic, time-eating, error-inviting" code method - you may wish to consider, "switching briefly to the API" - employing one of the (many) I2C code examples - getting that to quickly/easily WORK - and then review & log the various MCU I2C Registers - well revealed & exposed during such success.

    Most successful Tech firms seek (and expect) "some" efficiency from staff.    DRM - as you (and countless others) have discovered - seriously degrades efficiency - its use thus - proves, "Hard to justify!"     (I'd ask your instructor - or boss - "What efficiency and/or understanding?")    Many/most here - see NONE!    (you are "one of many" - having ship-wrecked - landed this barren shore - courtesy of DRM!)      WHY?

  • 0 in reply to cb1_mobile
    Prodigy 50 points

    Hi cb1_mobile,

    thanks for your effort. I am aware of vendor API. In This case, I am writing my own driver for I2C for education purpose. 

  • 0 in reply to Igor Misic
    Prodigy 50 points

    Ok, it looks like I resolved my problem.

    First, there is "issue" with CCS, it doesn't show MDR register with written data. It shows value only when data is received.

    But, even if the byte isn't shown in the register, it will be sent to SDA. I used Logic Analyser to find that out.

    Second, chapter 16.4.1 from TM4C123GH6PM datasheet says:

    10. Initiate a single byte transmit of the data from Master to Slave by writing the I2CMCS register with a value of 0x0000.0007 (STOP, START, RUN).

    So that is wrong!  If you set all 3 flags for STOP, START and RUN at the same time, data byte will not be sent.

    First, you need set START and RUN, and after that, you can STOP it.

  • 0 in reply to Igor Misic
    Guru 117855 points

    Igor Misic said:

    If you set all 3 flags for STOP, START and RUN at the same time, data byte will not be sent.

    First, you need set START and RUN, and after that, you can STOP it.

    Before "carving that solution in stone" - might it prove wise to: "Read/review the API code" (source is freely available) - seeking to determine if  "API code" too - demonstrates such, "multiple writes to I2CMCS."    

    While I've not done so - my expectations are that the, "Use of DRM" has (likely) caused/contributed to such "I2CMCS sensitivity!"

    Should my  "sense of DRM being the cause of your issue" - and you continue in its use - you may be "Inviting" further issues (in no way good) - which are avoided via your use of the, "LONG PROVEN" API.    

    Smart & skilled as you are - or will become - "single man's usage" cannot begin to compare w/the "massive work-out" the API has received - which makes API usage far "SAFER, EASIER & FASTER!"      (even "one" of those key benefits - would push  many/most:  "efficiency & "on-time delivery" seekers -  overwhelmingly - in the API's direction...)