TM4C123GH6PM: BUSBUSY flag is high after master enable

Greetings,

My small (outsider) team finds your description quite clear ... yet your "methodology" appears (at least somewhat) questionable.   

You note, "Where as soon as I set the master bit the BUS BUSY flag is = 1."    

We find that statement in (serious) need of further detailing:

• How did you make that determination?    Your "initialization sequence" (nicely listed, btw) appears to have ended at your step #6 - which "enabled the master bit."   (for clarity - do confirm that you wrote the I2CMCR register with a value of 0x0000.0010)
• If that proves so - and your initialization ceased then & there - was not the initialization "incomplete?"   Note that your MCU's manual (pg. 1016) lists an "additional 6 steps (total 12)" and it (may) be that "all of those steps are required" - to clear 'busbusy.'
• Further (pg. 1020 - I2CMCS reveal)  advises that bit, 'busbusy'  "Changes based on the START and STOP conditions."   Thus - it is possible (even likely) that your "Read of 'busbusy' (as your listing shows) was premature.
• And (pg. 1021) notes that the simpler 'busy' bit - "When set, invalidates all other status bits!"   Had you noted that - and if so - had you checked the 'busy' bit's level?    

It is believed that (multiple) "reasons" for your (potential) issue have been identified - and that the "fix" requires the full execution of the MCU manual's "12 step, I2C initialization process."   (pgs. 1015 & 1016)   

It remains of "interest" as to, "How & why you appear to have read the "I2CMCS" register after Step 6?"

first of all thank you very much for your fast reply ,

after executing this line of code the BUSBUSY bit is set and I can see that through the debugger window:

            RCGCI2C |= 1<<AssignedModuleNum;
            I2CMCR( AssignedModuleNum ) |= 1 << MasterEnableRegShiftBits;

given that:

AssignedModuleNum -> chosen module number 

MasterEnableRegShiftBits -> 4

i have followed the 12 steps mentioned in the datasheet pages you mentioned but as soon as I finish  the part of generating the (start,run &stop bits) the arbitration lost pin is set although its a single master system , so i wondered if that is due to the fact that the bus is always busy

the code in details :

    Port_Init();
    Port_SetPinMode( PORTA_PIN7, 0x03 );                                                //i2c mode selection
    Port_SetPinMode( PORTA_PIN6, 0x03 );                                                //i2c mode selection

    RCGCI2C |= 1<<AssignedModuleNum;                                                  //module enable
    I2CMCR( AssignedModuleNum ) |= 1 << MasterEnableRegShiftBits;    //masterbit enable

/* after the previous line the BUSBUSY is 1 on the  debugger window */

    I2CMTPR( AssignedModuleNum)=0x01;                                                //i calculated it previously

    I2CMSA(1)=0b11010000;
    I2CMDR(1)=PWR_MGMT_1;
    I2CMCS(1)=0x03;                                                                                //sends start and run

/* after the previous line the arbitration lost , busbusy and highspeed enable bits appear to be set  on the  debugger window */

    while(GET_BIT(I2CMCS(1),0)==1);   //waits until the i2c module is idle again
    I2CMDR(1)=0x00;
    I2CMCS(1)=0x05;
    while(GET_BIT(I2CMCS(1),0)==1);   //waits until the i2c module is idle again

Greetings,

Thank you for such a nicely detailed response.   Our small group will try to advise further - yet a "Major Simplification" is available - we'll hold that to the end.

Our observations:

• You wrote, "after executing this line of code the BUSBUSY bit is set and I can see that through the debugger window"

Yet we wrote earlier that the I2CMCR Register description advised that 'busbusy' may not prove valid until all 12 steps complete!

• Your code adopts the "Direct Register" format - which (very) deeply requires (near) total, "Individual Register Focus."   That presents a far higher (and longer) challenge - especially when the vendor has supplied a "highly successful, proven & robust API."

The usual justification for employing "Direct Register and/or ASM coding" is to, "Speed Code Execution and/or (or both) Reduce  Code Size."   That said - your code is a simple initialization sequence - little benefit accrues from such 'advantages.'

Surely this vendor will recommend, "Use of the API code" - and we fully agree.   (especially in the case of initialization)

We cannot tell if your Slave I2C device was properly connected (best to employ external pull-up resistors upon (both) SCL & SDA) and we'd always start at the slowest speed (100KHz) should the slave accept that.

As/if time allows we will employ the API to transact w/an I2C Slave device using your MCU - and report.   The API will enable a "FAR Quicker & Easier" means to "guarantee proper I2C (and other peripheral) initialization!"    (we will then compare/contrast the API's Register Values vs. those which you've presented...)

The danger of your "DRM" usage is that, "You are in the Pioneering Mode" (there is no successful history for you to fall back upon) and many/most "pioneer trails" are unpaved - littered w/"Dead/bleeding Pioneers!"     (While the "API trails" are pristine blacktop - w/traffic flowing @ high-speed...)    Might you (too) - consider a, "Better road?"

Hello Ahmed,

As cb1 mentioned already, you should be using TivaWare for this application. It will greatly simplify this sort of application and there a number of I2C examples for the Senshub BoosterPack provided which you can reference to get running.

We do not support DRM programming on E2E per: https://e2e.ti.com/support/microcontrollers/other/f/908/t/695568

If you cannot shift to using TivaWare to simplify your issues and get TI support, then my advice would be to look at the I2C initialization APIs from our example code and study the calls they make and the order of the calls. That and review the advice from cb1 including the hardware checks.