SMB/I2C short clocks look like glitches to slave

Dan Beadle said:

I am having problems reading reliably over SMBus using the Utils. 

Find your post very much beyond average in its detail & presentation - good that.

Yet - you list your issue as one of "reading reliably" which strongly suggests that (some) data transfers occur as expected.    (w/out incident - is this correct?)    If so - have you tested to see if there's something unique to this 0x17 transmission - which aids/abets this (apparent) glitch?

As always - "single board anomalies" prove the bane of, "remote troubleshoot crue!"    Does this occur across multiple MCU boards - and multiple Slaves?      And - always (and only) with this exact data?    

May I suggest separate testing - with a different slave device (ideally one requiring a different slave address) to see how/if the issue presents?

And - you provide no info as to (other) residents - this SMB bus!    (anything present is a suspect - at this early stage)

"Inside info" - guarded/stored @ vendor's (pristine HQ) always proves of interest - and (somewhere) I recall this 0x17...    (although "fog of battle" dulls link ability to such recall)  

Might you (further) detail?

Thank you - 2nd post "out did" your (excellent) initial one.

And - indeed, "checked the normal things" you (surely) did!

My firm buys volumes of Li Ion (smart) batteries - assume yours are similar. (ours from firm "S")    If you choose to "id" your smart battery I'll see if we have it (or near equivalent) and repeat your test on (several) of our multi-vendor ARM MCUs.     Such would seem conclusive.
 
I've some concern about the, "two batteries" attached. Temporarily - till similar glitch occurs - might you try w/just one?

Believe your test w/"non-battery, SMBus slave - never becoming a master - & w/Smart Bat. registers" was particularly inspired! And its use - revealing the same sort of errors - raises the MCU to, "prime suspect."

Pardon - but have you "combed" latest/greatest errata?

I'm (almost) out of tricks - but a repeat of that (most always) failing SMBus "0x17 transaction" via, "bit-bang" may (conclusively) prove some defect w/in vendor MCU's SMBus implementation - would it not?

Hi Amit,

As I read - it is your MCU's (output) clock pulse - which (appears) to be glitching!    Is the glitch filter intended to prevent an (MCU output) glitch?

Yes, this is a continuation of the original issue.  

I found that I was not handling errors from the SMB stack correctly.  When I started handling BUS_BUSY, ARB_LOST, BUS_TIMEOUT, reliability got much, much better.    In that case, I had clocks that were fairly wide - and short.  Once I correctly ( or at least more correctly ) handled these errors, the runt pulses went away.

My config code is based on using the library reference:

uint32_t SysClk = SysCtlClockGet();

SMBusMasterInit(&Context, BaseAddress, SysClk );

IntPrioritySet( InterruptAddress, 5<<5 );  

// Set up glitch filter.

I2CMasterGlitchFilterConfigSet( BaseAddress, I2C_MASTER_GLITCH_FILTER_32); // todo

SMBusMasterIntEnable( &Context );

MTPR was correctly set at 18x (100Khz).

The set up of the glitch filter does not appear to be correct when I use the call to I2CMasterGlitchConfigSet.

void
I2CMasterGlitchFilterConfigSet(uint32_t ui32Base, uint32_t ui32Config)
{
//
// Check the arguments.
//
ASSERT(_I2CBaseValid(ui32Base));

//
// Configure the glitch filter field of MTPR.
//
HWREG(ui32Base + I2C_O_MTPR) |= ui32Config;
}

It is attempting to write to the MTPR which has no bits in the shifted position.  It should be writing to I2C4MCR2.  Also, it never sets up the GFE bit in I2C4MCR.

This is the code that I used from the TivaWare_C_Series-2.10.0.12573 library:

//*****************************************************************************
//
//! Configures the I2C Master glitch filter.
//!
//! \param ui32Base is the base address of the I2C module.
//! \param ui32Config is the glitch filter configuration.
//!
//! This function configures the I2C Master glitch filter. The value passed in
//! to \e ui32Config determines the sampling range of the glitch filter, which
//! is configurable between 1 and 32 system clock cycles. The default
//! configuration of the glitch filter is 0 system clock cycles, which means
//! that it's disabled.
//!
//! The \e ui32Config field should be any of the following values:
//!
//! - \b I2C_MASTER_GLITCH_FILTER_DISABLED
//! - \b I2C_MASTER_GLITCH_FILTER_1
//! - \b I2C_MASTER_GLITCH_FILTER_2
//! - \b I2C_MASTER_GLITCH_FILTER_3
//! - \b I2C_MASTER_GLITCH_FILTER_4
//! - \b I2C_MASTER_GLITCH_FILTER_8
//! - \b I2C_MASTER_GLITCH_FILTER_16
//! - \b I2C_MASTER_GLITCH_FILTER_32
//!
//! \note Not all Tiva devices support this function. Please consult the
//! device data sheet to determine if this feature is supported.
//!
//! \return None.
//
//*****************************************************************************
void
I2CMasterGlitchFilterConfigSet(uint32_t ui32Base, uint32_t ui32Config)
{
//
// Check the arguments.
//
ASSERT(_I2CBaseValid(ui32Base));

//
// Configure the glitch filter field of MTPR.
//
HWREG(ui32Base + I2C_O_MTPR) |= ui32Config;
}

It is clear that it is putting the value into the wrong register.  It should be MCR2 per the datasheet The defines for the values are also wrong:

#define I2C_MASTER_GLITCH_FILTER_32 \
0x00070000

Finally, the routine doesn't set the GFE bit of MCR.  

I will change my code to:

HWREG(BaseAddress + I2C_O_MCR2 |= 7<<4; // Set to 31 clock glitch filter

HWREG(BaseAddress + I2C_O_MCR) |= I2C_MCR_GFE; // and enable now

I should have checked the registers earlier.  I had hoped to leverage libraries.  

I will let you know how this works.

Amit Ashara said:

There are a bunch of document updates being planned so we can go and update Driver Lib User Guide appropriately.

Hi Amit,

Surely your group has given great thought to these updates.      And they'll be received with joy by many users.

That said - might a simple listing of those updates here (i.e. no great detail - rather just the names/targets of the updates) prove worthwhile?     Your user-clients here may well be able to suggest: additions, prioritizing of those updates, & other "useful comments/feedback."    

We note that "Community Feedback" is often helpful - appears that it could enhance/enrich your, "planned document updates."    (i.e. many more eyes/ears/ideas often improves the "appropriateness" of work done by a, "select few!")       And - of some note - we're free!