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.
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))
{
}
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
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.
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' . . .
"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."
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.
@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...