• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 31 subscribers
  • Views 610 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.

Stellaris Launch Pad LM4F120XL I2C

Geet Modi
Mastermind 26320 points

Hi,

I am trying to use I2C peripheral on the board. I tried using the i2c peripheral example ( master_slave_loopback.c). 

It executed well for the first time... I could see the prints on Hyperterminal of both Master to Slave and Slave-Master transmission of  data. But when I execute it for the second time, it get stucks in the following while loop and never comes out.  Looks like some effect of the previous execution. It does not recovers even after reset, power cycle of the board. Only way to recover is keep the board unpower for 2-3 hours. Kindly help.  I am using IAR Tool for compilation and no change in the standard example code. 

Regards,
Geet

 

//
// Wait until the slave has received and acknowledged the data.
//
while(!(I2CSlaveStatus(I2C0_SLAVE_BASE) & I2C_SCSR_RREQ))
{
}

  • 0
    Guru 17650 points

    Hi,

    what do you meen with 'execute it for the second time'? Don't attempt to single-step I2C communication; use breakpoints instead.

    aBUGSworstnightmare

    P.S. Find my I2C Master API in the Sharing Section of the Forum http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/473/t/235926.aspx

  • 0 in reply to Joerg Quinten
    Guru 117855 points

    aBUGSworstnightmare said:
    'execute it for the second time'?

    @ Bug: Suspect his meaning is a 2nd RUN of the program - so single steps or breakpoints are not likely in play.

    @ Poster Geet: How certain are you that the 2nd (or additional runs) truly start and initialize in exactly the same manner - as your successful, initial run?  My bet is one or multiple critical bits/events have been altered during initial run. 

    Your stated requirement for such long, "cool-down" (2-3 hours) is unusual - suggest a different PC and or USB cable.  (and beware many "questionable connects" now long reported @ USB connector on that board...)  Really makes little sense - unless you have other connections to this board which have not been reported...

    Update: wonder if your board has the requisite pull-up Rs - on both SDA and SCL?  Such long "cool-down" leads to this as candidate source of your issue...

    As your Slave appears to either have failed to ACK - or "missed" the data - suggest that you insure that master has indeed properly transmitted.  Once that is confirmed - you should be able to monitor Slave register for data's presence and w/scope observe Slave's ACK. 

     

  • 0 in reply to cb1_mobile
    TI__Mastermind 26320 points

    Hi,

    wonder if your board has the requisite pull-up Rs - on both SDA and SCL?

    How to check this ?

    See below the Hyperterminal dump of the program.

     

    I2C Loopback Example ->

     

       Module = I2C0

     

       Mode = Single Send/Receive

     

       Rate = 100kbps

     

     

     

    Tranferring from: Master -> Slave

     

      Sending: 'I'  . . .  Received: 'I'

     

      Sending: '2'  . . .  Received: '2'

     

      Sending: 'C'  . . .  Received: 'C'

     

     

     

     

     

    Tranferring from: Slave -> Master

     

      Sending: 'I'  . . .  Received: 'I'

     

      Sending: '2'  . . .  Received: '2'

     

      Sending: 'C'  . . .  Received: 'C'

     

     

     

    Done.

     

     

     

    I2C Loopback Example ->

     

       Module = I2C0

     

       Mode = Single Send/Receive

     

       Rate = 100kbps

     

     

     

    Tranferring from: Master -> Slave

     

      Sending: 'I'  . . .  I2C Loopback Example ->

     

       Module = I2C0

     

       Mode = Single Send/Receive

     

       Rate = 100kbps

     

     

     

    Tranferring from: Master -> Slave

     

      Sending: 'I'  . . .

    2C Loopback Example ->

     

       Module = I2C0

     

       Mode = Single Send/Receive

     

       Rate = 100kbps

     

     

     

    Tranferring from: Master -> Slave

     

      Sending: 'I'  . . .  I2C Loopback Example ->

     

       Module = I2C0

     

       Mode = Single Send/Receive

     

       Rate = 100kbps

     

     

     

    Tranferring from: Master -> Slave

     

      Sending: 'I'  . . .

     

  • 0 in reply to Geet Modi
    Guru 117855 points

    "Wonder if your board has the requisite pull-up Rs - on both SDA and SCL?"  ... from cb1 (earlier)

    Geet Modi said:
    How to check this ?

    Timeliness of response well matched to nature of such question...

    You may review the board's schematic - further measure resistance from 3V3 to both SDA and SCL pins - with board unpowered.  Usual value of such pull-ups ranges between 2K2 - 10K. 

    You are silent wrt any possible alterations in the "re-launch" procedure of your I2C call.  If the pull-ups are present - then it is most likely that some initialization and/or set-up has been altered between "pass" runs and "failed."

  • 0 in reply to cb1_mobile
    Prodigy 40 points

    I've had (Microchip PIC) chips which would keep their RAM/setting register contents after power down for multiple hours due to residual charge. So it seems to me that some registers are not getting cleared during initialization, and the settings/status from the previous transmission is still in there.

  • 0 in reply to Anthony VH
    Guru 117855 points

    @Anthony,

    Sure - agreed - however one would suspect that user's Registers were set correctly - for his initial RUN to succeed. 

    Thus - if not altered during his subsequent RUNS - he should again function properly.  (and does not)

    I'm never thrilled w/Loopback as sole test mode - too many things have to function "just right" - KISS seems to work far better...