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.

TM4C129ENCZAD: I2C write transaction not latched into slave device written to.

Part Number: TM4C129ENCZAD
Other Parts Discussed in Thread: TMP006, ADS7924

HI,

Hoping this is a code issue someone might has crossed before. I can successfully read the various control and status registers via I2C, with a slave device (running CCS V7.1.0.00016 debugger,, no rtos, custom board with TM4C129ENCZAD master, and slave device IIS2DH).

When I write to one of the control registers (for ex., CTRL_REG1) on the slave device, and then read back the new state, the original (power-up default) value is returned, not the new value just written.

This register has a power-on default of 0x07. It never changes for any write op that I have come up with. After studying the forums herein, at this point, have the code inserted at the end of this post.

The code first reads current (default, 0x07)) state of ctrl1. Then a new value (0x23) is written to ctrl1. Finally, the new state of ctrl1 is read back.

The problems:

1) A write to a control register appears to not be latched by device. This may be a device issue and not a code issue but I am wondering if it may be something in the write sequence I have arrived at (see code below...)

2) The last read op repeats 2x's. No clue why.

The following screen capture shows the bit sequences transmitted across the I2C SDA/SCL for the above 3 ops.

As can be seen, the state of ctrl1 does not change in response to the write op. And the final read op repeats 2x.

The following is the code:

   //program CTRL_REG1[7:4] to 0111 - 400Hz HR/NORMAL/Low Power Mode (def = 0000 - PowerDn)
   //Read current state of  CTRL_REG1
   SlaveAddress = 32;  //CTRL_REG1 address (x20)
   //SlaveAddress = 15;  //WHOAMI address (x0F)
   I2CMasterSlaveAddrSet(I2C2_BASE, Board_FBB_TM4C129_ACCEL_ADDR, false);  //false = write
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 delay issue - from TI forums. Subsequent code steps will not work reliably w/o this!!!)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));
   
   I2CMasterDataPut(I2C2_BASE, SlaveAddress);
   I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_SEND);
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));

   I2CMasterSlaveAddrSet(I2C2_BASE, Board_FBB_TM4C129_ACCEL_ADDR, true);  //true = read
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));
   
   I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_RECEIVE);
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));

   Slave_CTL_Reg1_State = I2CMasterDataGet(I2C2_BASE);

   //Set bits [7:4] = 0111, ODR field for NORMAL Mode ops
   MasterTxData_R = Slave_CTL_Reg1_State;
   MasterTxData_S = (MasterTxData_R & 0x00) | 0x23;

   SlaveAddress = 32;  //CTRL_REG1 address (x20)
   I2CMasterSlaveAddrSet(I2C2_BASE, Board_FBB_TM4C129_ACCEL_ADDR, false);  //false = write. This transmits correctly, when I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_SEND) is run
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));
   
   I2CMasterDataPut(I2C2_BASE, SlaveAddress);
   I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_SEND);
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));

   I2CMasterDataPut(I2C2_BASE, MasterTxData_S);  //write updated CTRL_REG1 setting
   I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_SEND);
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));

   //Check new state of  CTRL_REG1
   SlaveAddress = 32;  //CTRL_REG1 address (x20)
   I2CMasterSlaveAddrSet(I2C2_BASE, Board_FBB_TM4C129_ACCEL_ADDR, false);  //false = write.
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));
   
   I2CMasterDataPut(I2C2_BASE, SlaveAddress);
   I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_SEND);
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));   

   I2CMasterSlaveAddrSet(I2C2_BASE, Board_FBB_TM4C129_ACCEL_ADDR, true);  //true = read.
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));
   
   I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_RECEIVE);
   SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
   //while(!(I2CMasterBusy(I2C2_BASE)));
   while(I2CMasterBusBusy(I2C2_BASE));

   Slave_CTL_Reg1_State_Verify = I2CMasterDataGet(I2C2_BASE);
   if(uint8_t(Slave_CTL_Reg1_State_Verify) !=MasterTxData_S)
      {
      System_printf("I2C Rd/Wr to CTRL_Reg1 Error");
      return 0;
      }

Have read, re-read, and read again the user guide for the I2C slave peripheral. No special commands to enable register changes are mentioned. I posted to the tech support site for the part but have not received any feedback yet. Again, hoping its something in my code that is not right.

Thank you in advance.

  • Well, my screen capture didn't make it. Trying one more time here:

  • erik skullerude said:
    The following screen capture shows the bit sequences transmitted across the I2C SDA/SCL for the above 3 ops.

    Even - "Little Stevie Wonder" could not see that cap!    (later - 2nd post revealed)

    Before performing forensic code review - it should be asked:

    • have you employed external pull-up Rs upon your JTAG signal lines?     (the arrival of  "0x07" may NOT require a successful write!)
    • have you "scoped" those lines?    (logic analyzer does not properly reveal waveforms)
    • have you attempted to write to (other) slave registers - and note if this issue persists?
    • what is the separation distance between the Slave device & MCU?    Are they together - on the same board?
    • have you tested a "Second such Slave device" to determine if the issue persists - and is unchanged?      Single device anomalies should be eliminated prior to "help requests."
    • might your use of a (very) small/simple, I2C based EEprom - enhance your troubleshooting?    (i.e. think "KISS" - simpler device is far easier/faster to debug)

    Wish that I had more - yet sense this new data may "lead the way" toward your success...

  • Look at the ST datasheet, you need to send the slave address (0x18 or 0x19 depending on how you connected the SA0 pin) as a write, followed by the register address.
    Disclaimer: As a TI employee I am not an expert in ST devices. For more information on the ST IIS2DH you can contact ST.
  • Hi Cb1_mobile,

    -pullups in place (probe leads soldered to line side of pullup R's). Pullups are ~0.5 inch trace length from vias out of TM4C part
    -need scope traces; sometime today.
    -write to SlaveAddress = 30, ACT_THS, address (x1E), had same outcome, no change observed in read-back.
    -MCU to slave has trace length maybe 1.25 inch total, plus 3 vias.
    -switched to a different board with a slightly different version of this part. Same behavior.
    -switched to TM4C129EXL eval board, connected to a BME280 PTH sensor (this one has a bit simpler interface). Same outcome (running the same code, just recompiled with updated addresses).
    -Don't have any other devices handy to test with. At this point, 3 devices with 3 different boards - really appears there is something wrong in my write approach but I don't see it. Will look at some DSO captures.

    I have screen captures of the above transactions but inserted images to this post are not displaying.

    Thanks again for your input.

  • erik skullerude said:
    I have screen captures of the above transactions but inserted images to this post are not displaying.

    Sometimes that happens - but "just in case" I'll outline a procedure which (usually) works for us.

    • You must be in the "Use Rich Formatting" screen mode for this icon grouping (above) to display   (found at the right, bottom of your "active" post)
    • Item in surround enables you to "paste" your cap into your post - (at the current cursor location.)    The cap must be "saved & resident" w/in the directory pointed to by this "insert/edit media" icon.

    Your most recent post is terrific - no one (least of all me) could ask you to do more - thank you - very systematic & clearly detailed!

    Most always - dialing DOWN the I2C data rate helps.   (I've not high hopes - but "worth a try.")

    Thus far - I've (not) made a proper effort to read/review your code - with the arrival of your scope caps - (unless they provide, "Eureka") - I will make such code read/review.

    Your "capture probes" are, "0.5" from the MCU - would not their placement @ the Slave device prove worthwhile?   (two caps - w/2 different probe placements - ideal)

    I2C holds such "promise" - yet proves sufficiently "trying" to MCU user souls...   (i.e. Feel your pain)

  • Thanks for clarifying file uploads. In fact, that is exactly what I tried, repeatedly. What I end up with is what you noted in the original post, a tiny little icon where the image should be.

    Also tried pasting from Word, as well as the "insert file" (via the paper-clip icon). All fail. Do you have a public facing FTP site I can push it onto?

    Re. probes, the parts are BGA's. There are no vias into the top layer so that isn't an option.

    Re. the code, keep in mind what I've posted is primitive; only for figuring out how to get this interface operational. Ultimately, this all has to run as a task in TIRTOS. I'm grinding my teeth, anticipating how I'm going to translate this over. My first attempt with running an I2C task in RTOS crashed at the first transaction.

    Will try again later to post those captures. Its worked before. Maybe it only works at certain times of the day (angle of the sun perhaps?).

    Thanks again.

  • Your attitude remains good - while the issue frustrates - firm/I have "never failed" to "coax the I2C peripheral to perform" - across 4 different ARM MCUs - from 3 different vendors.    (one of these our "fav" - Cortex M7)

    We have only employed "Insert/Edit Media" w/files saved as "JPG or TIF" - again the forum's insert function (demands) that your "cap" be resident w/in the file pointed.    (You cannot "Insert/Edit" via the simpler/faster "Ctrl_C" - followed by "Ctrl_V."

    I managed to sprain my wrist yesterday - "walking."     Sidewalk had a 2" protruding lip - which I did not note - and I was walking fast. (to rent a truck for a visit to our external warehouse.)     I then drove the truck "one-handed" (yielding only "slightly" degraded "lane maintenance.")     (who cares?      this is my "hedge" if pain returns - and I cannot type one handed...)

  • Sorry to hear about your wrist - I did that once. Was extremely painful. Hope you are icing it...

    Probed the SCLK with a DSO - looks suitable. Appears there is enough capacitance on the line and low (I guess) drive strength to cause a well rounded rising edge. It hasn't been a problem for the reads. I still need to figure out how to slow down the speed; I recall seeing something in one of the command descriptions about this.

    Also, I have a question - this is really down in the details. For all three devices I've tested, the data sheets shows clearly in each case, for a write cycle to a slave address, the sequence is as follows:
    -set up the slave address and that we are doing a write
    -set up the corresponding sub address
    -write the data

    There is a great transaction sequence figure that shows this clearly ( I could attach here but that feature is not working ). If you can, please download the following data sheet and goto page 24 and look at Table 15 - Master signal byte write sequence.

    Data sheet here: http://www.st.com/content/ccc/resource/technical/document/datasheet/group1/35/6d/04/26/27/5c/4d/7c/DM00171283/files/DM00171283.pdf/jcr:content/translations/en.DM00171283.pdf

    Compare that to the LA capture (it will be hard but if you zoom in, and use a finger or edge of paper slip to line up clk pulses with data), you will see there is an extra start/address cycle between the sub-address cycle and the data byte write. We are puzzled by this extra cycle and it sure doesn't match Table 15 in the above data sheet.

    The code portion that executes the write sequence is repeated here for clarity:

    //set up slave address and write cycle
    I2CMasterSlaveAddrSet(I2C2_BASE, Board_FBB_TM4C129_ACCEL_ADDR, false); //false = write
    SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
    //while(!(I2CMasterBusy(I2C2_BASE)));
    while(I2CMasterBusBusy(I2C2_BASE));

    //set up the sub-address
    I2CMasterDataPut(I2C2_BASE, SlaveAddress);
    I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_SEND);
    SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
    //while(!(I2CMasterBusy(I2C2_BASE)));
    while(I2CMasterBusBusy(I2C2_BASE));

    //send the data - write updated CTRL_REG1 setting
    I2CMasterDataPut(I2C2_BASE, MasterTxData_S);
    I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_SEND);
    SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)
    //while(!(I2CMasterBusy(I2C2_BASE)));
    while(I2CMasterBusBusy(I2C2_BASE));

    What do you think?

    Thank you.

  • Few posts here match yours for clarity & detail - much appreciated. I'll do my best to review your caps - and code - I used to be an Eng. Mgr. @ the firm you noted - they supply our Cortex M7.

    I recall there often is a challenge to distinguish between "Repeated Start" (engage vs. disengage). This occurs during multi-byte I2C transmissions - has "tripped up" its share of victims. Do understand our (other M4s & M7s run far faster than your 129 - thus we've never found it appealing - have none! (and - delightfully - the I2C set-up code, qualification & maybe other elements - represent new learning - but I will make the effort.

    ICE indeed - my wrist is good 1.25" larger than its "non-strained" twin - and my "range of slight motion" is expanded. I'm back to our external warehouse now - suspect 5 or so hours before I can return. (our back-room behind a back-room office complex is too "high-rent" to justify as storage/warehouse - thus we use a temperature controlled - yet bit distant - external facility...)
  • In case you want to see how I am initializing the I2C, here is the init function (which is the last call before the transaction code posted above):

    void TM4C129_initI2C(void)
    {
    /* I2C2 Init - Enable the peripheral */

    uint32_t ui32SysClock;

    //Config IO's - Enable GPIO for Configuring the I2C Interface Pins
    //
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOG);

    //
    // Wait for the Peripheral to be ready for programming
    //
    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_GPIOG));

    //
    // Configure Pins for I2C2 Master Interface
    //
    GPIOPinConfigure(GPIO_PG2_I2C2SCL);
    GPIOPinConfigure(GPIO_PG3_I2C2SDA);
    GPIOPinTypeI2C(GPIO_PORTG_BASE, GPIO_PIN_3);
    GPIOPinTypeI2CSCL(GPIO_PORTG_BASE, GPIO_PIN_2);

    //Config I2C Controller:
    // Setup System Clock for 120MHz
    //
    //ui32SysClock = SysCtlClockFreqSet((SYSCTL_OSC_MAIN | SYSCTL_USE_PLL | SYSCTL_XTAL_25MHZ | SYSCTL_CFG_VCO_480), 120000000);
    ui32SysClock = SysCtlClockFreqSet(SYSCTL_OSC_INT | SYSCTL_USE_PLL | SYSCTL_CFG_VCO_320, 40000000);

    //
    // Stop the Clock, Reset and Enable I2C Module
    // in Master Function
    //
    SysCtlPeripheralDisable(SYSCTL_PERIPH_I2C2);
    SysCtlPeripheralReset(SYSCTL_PERIPH_I2C2); //Clears I2C_SCL pad, allowing pull-up to '1'
    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C2);

    //
    // Wait for the Peripheral to be ready for programming
    //
    while(!SysCtlPeripheralReady(SYSCTL_PERIPH_I2C2));

    //
    // Initialize and Configure the Master Module
    //
    I2CMasterInitExpClk(I2C2_BASE, ui32SysClock, true); //false
    SysCtlDelay(10000); // delay mandatory here

    }
  • Following is the LA captures of the step-by-step (via CCS debug) read, write to and read-back from ctrl reg1. Slave I2C address is 0x19, sub-address (reg1) is 0x20.

    Note the "extra" start/address cycle between the address cycle for the write and when the data byte is sent (3rd and 4th waveforms). Data sheet shows sequence should be sub-addr followed by data byte. Is it possible the slave gets messed up when the second start/address is sent just before the data byte?

  • erik skullerude said:
    ... Sequence should be sub-addr followed by data byte.    Is it possible the slave gets messed up when the second start/address is sent just before the data byte?

    It appears that your original post included the device number for the <enemy> device - which subsequently disappeared.    I just now noted your spec link - will review that later this day.

    You must "duplicate" the Slave's requirements as much  as possible & your quote shows that you've made that recognition.

    I do note that much of your I2C code appears (very) similar to my firm's "4C123 I2C code."     That  said - I believe that there ARE differences - especially the back to back "check of a status flag" - required by the129 class device.   (although  that may be only required to maximize thru-put during I2C interrupt operaions.)     I will find & review your recent link - then respond.

  • Hi, sounds great - really appreciate you taking a look.

    For what its worth, I posted a follow-up question on the STM case I've had opened for a week (no reply yet...), asking specifically if the second start/address cycle (which I think is just a restart) may be an issue.

    This is the first time I've delt with STM so don't know if they always reply to questions.

    Anything I learn will post here.

    How is your wrist doing? IIRC, it was a couple of weeks for mine to regain some reasonable range of motion.

    Thanks again.

  • Ok - my 7th grade, NYC "Touch Typing" teacher would "turn in her grave" watching me "One finger" this post.

    I've tried your new link - at least 5 times - results always in "404 - file not found!" I noted that the link "over-flows" my screen page - and there are no "horizontal scroll arrows" w/in your posting - so it's unclear if I'm copying the entire link.

    We have worked many times w/I2C devices - requiring Slave Address - then target register - and then multi-byte data. (SX1505 and a 12 bit, I2C ADC from this vendor: "7924 is top-mark - maybe ADC7924 is the part number.") Your comparison of my device's access requirements - vs. yours - may yield a simple solution (I'll PM you our successful I2C code).

    It may be that your selection of an "off chip" I2C device - like ours - sought a "low pin-count" means to add - or expand - functionality. In our case - we exhausted all of the MCU's ADC channels - had to go "off chip" to meet client's demand. And that worked. (after (some) pain/suffering iirc.)
  • HI,
    Re. link to device DS, please go to Digikey.com, then in the part number search box, enter: IIS2DH. There will be 3 results - pick the 2nd one in the list. On that page, under Documents and Media, there is a link to the data sheet. Then once open, scroll down to p. 24, view table 15 - compare against the captures I posted last night (waveform 3 and 4).

    I would like to see your code - how do i securely share my PM???

    Thank you.
  • Hi Erik,

    If you have TivaWare installed, you might want to review the example in: "C:\ti\TivaWare_C_Series-2.1.4.178\examples\peripherals\i2c\soft_i2c_atmel.c". This Atmel device example also uses a slave address and sub addresses. The implementation in this example uses burst mode to send the address, sub address and data on writes. It uses interrupts and static variables to avoid stalling between the writes which makes it a little more complex to follow, but I think it will help you.
  • HI Bob, thank you for the input. I believe i looked at that example - that is the tmp006 (temp sensor?). I will look again next week. Heading out of town for a few days. Thank you again for your time and support.
  • As the vendor has returned - best you focus upon his direction, inside info & interest.

    By "mousing over" vendor's or my avatar/id - you'll note, "Send a Private Message."

    That capability was achieved during your "set-up" for this forum - and you should be able to return - and then "click that PM box."

    There exists a "Message Present" icon (3rd from the right, atop the forum page) which alerts upon message arrival.

    I'll serve as "back-up" - if & while my wrist heals - or (should) your issue linger...

  • While my wrist "pounds" (cannot sleep) felt it better to be (somewhat) productive.     Have now well read/reviewed your slave device's manual.

    Rev 2 spec lists the following (the clarity & detail of this diagram (Sending Multiple Bytes to the Slave) must be noted.)

    As suspected - NO "Restart" is directed!    (Legend: ST=Start, SAD=Slave Adr, SUB=sub Adr; SAK=Slave Ack; SP=Stop)   (IMO - a very effective, (xtal clear) presentation of data sequence.)

    For simplicity - you should be starting w/Single byte writes to the Slave.    (and here - for added clarity - is the diagrammatic guidance for such task.)   Again - NO Restart is to appear.

    And this table reviews the various Slave Addresses.    (influenced by both R/W & SA0 pad on the Slave)

    Now in a recent posting you wrote: "Slave I2C address is 0x19, sub-address (reg1) is 0x20."    That 0x19 is NOT the Slave Address - which must comply w/the chart, above.     Yet - as you (were) able to read the "sub-address" you must have (at least once) entered the proper Slave Address.

    And now your FIX...    As you questioned - you must PREVENT the generation of the 2nd Start Condition w/in your "Single Register Write to Slave transaction!"    As firm/I do not like nor use 4C129 - I'm not sure that our past (successful) I2C code (for 4C123) will be fully appropriate.   (yet still I'll send it once your PM functions)     You must scan thru driver lib file: "I2C.c" - searching for "Multi-Byte" (vendor may call this "Burst" transaction - and this surely enables a "cascade of  "Writes to Slave" WITHOUT embedding the (destructive/unwanted) Start Condition!     (I have NO doubt that the "extra" Start condition - "does you in!")

    We should note that your code made (near) exclusive use of, "I2C_MASTER_CMD_SINGLE_SEND()" function calls - and you must ask, "Might this function (always) embed the Start Condition?"     And then - if so - what alternatives (if any) may be available?

    Here now the function under "StellarisWare" which we past used - to send multiple I2C based bytes - while "avoiding" the (always) tormenting "extra" Start Condition.

    14.2.2.5 I2CMasterControl                                      *** Again this an extract from Driver Lib User Guide - Stellaris 9453. ***
    Controls the state of the I2C Master module.

    Prototype:
    void
    I2CMasterControl(unsigned long ulBase,
    unsigned long ulCmd)

    Parameters:
    ulBase is the base address of the I2C Master module.
    ulCmd command to be issued to the I2C Master module.

    Description:
    This function is used to control the state of the Master module send and receive operations.
    The ucCmd parameter can be one of the following values:

    I2C_MASTER_CMD_SINGLE_SEND   ........................................embeds Start Condx       cb1       
    I2C_MASTER_CMD_SINGLE_RECEIVE
    I2C_MASTER_CMD_BURST_SEND_START   ..................embeds Start Condx       cb1
    I2C_MASTER_CMD_BURST_SEND_CONT     ................NO embedded Start!     cb1
    I2C_MASTER_CMD_BURST_SEND_FINISH    ...............embeds Stop Condx       cb1
    I2C_MASTER_CMD_BURST_SEND_ERROR_STOP
    I2C_MASTER_CMD_BURST_RECEIVE_START
    I2C_MASTER_CMD_BURST_RECEIVE_CONT
    I2C_MASTER_CMD_BURST_RECEIVE_FINISH
    I2C_MASTER_CMD_BURST_RECEIVE_ERROR_STOP
    I2C_MASTER_CMD_QUICK_COMMAND
    I2C_MASTER_CMD_HS_MASTER_CODE_SEND

    I believe that your (proper) use of those parameters (both in highlight & italics) will "tame" your issue.

    Note that you must precede each such "Burst" function w/a proper call to "I2CMasterDataPut()."

    Our past/successful "multi and/or single byte" transactions w/vendor's ADS7924 "proved" the success of this method.

    Rather than "spoil" a "teaching moment" - your review of file "I2C.c" source - and (quick/dirty/eased) experimentation - will easily enable your confirmation of these methods...

  • Hi, this is the kind of solid guide post I needed. Thanks very much. I did not make this connection after searching thru the I-20 section in the tiva lib ug. I'm out of town for a few days; will try your suggestion when I get back next week. BTW, ST Micro support responded. Said my waveforms don't look right, and asked a few questions. Will post an update next week. Thx again for your time and help.
  • Thank you - wanted to "calm your mind" (at least somewhat) thus the 03:00 (Friday morn) onslaught.

    Vendor's literature could do a (better) job of noting both, "When and when not" the Start Condition appears - via the variety of "I2CMasterControl()" parameters.     (you'll note I've made that effort)

    You should review your choice of "0x19" for Slave Address - cannot be correct. (and unlikely to be a "typo.")     Again - I've presented the defining Slave Address Matrix in chart form for you.   (i.e. all key data "handy" in one place (i.e. that single post) - "just as my small firm prescribes")

    While you characterize my "fix" as a "suggestion" - we've "run the code" - NO/ZERO unwanted Start Conditions were noted!       (under your code - such were plentiful - and thus "spoiled" the "Writes to your Slave.") (this is not to say that you are "home-free" - yet the key/critical "unwanted Start Condx." has been localized - and the "mop up" should (now) be well w/in your capability.)

    As the forum's claimed (upgrade?) has "Banned the LIKE" - might you award, "Suggested Answer Resolved My Issue" to that 03:00 (sore-wristed) yet "solid" (your word) idea & data guide  - done in your behalf... 

  • Sorry I'm so very late in replying. I mentioned in my last post I would be out for a few days. However, one thing lead to another and a month has past... Finally got a chance to even take a look at this and apply the changes CB1_MOBILE suggested in previous post. This solved the problem. So the sequence I'm using to write to a slave device register:

    //Set up for write to slave

      //SlaveAddress = 32;  //CTRL_REG1 address (x20)

      I2CMasterSlaveAddrSet(I2C2_BASE, Board_TM4C129_ACCEL_ADDR, false);  //false = write.

      SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)

      while(I2CMasterBusBusy(I2C2_BASE));

    //write data to slave

      I2CMasterDataPut(I2C2_BASE, SlaveAddress);

      I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_BURST_SEND_START);   //Per CB1_Mobile

      SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)

      I2CMasterDataPut(I2C2_BASE, MasterTxData_S);  //write updated CTRL_REG1 setting

      //I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_SINGLE_SEND);

      I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_BURST_SEND_CONT);     //Per CB1_Mobile

      SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)

      I2CMasterDataPut(I2C2_BASE, SlaveAddress); 

      I2CMasterControl(I2C2_BASE, I2C_MASTER_CMD_BURST_SEND_FINISH);    //Per CB1_Mobile

      SysCtlDelay(1000); // Allow Busy flag to set (TM4C129 issue)

      while(I2CMasterBusBusy(I2C2_BASE));  

    LA capture of SDA/SCL during a read-write-read sequence to slave sub-address x20:

    Thank you again CB1_MOBILE.