Hi,
I'm developing an I2C slave device based on a MSP430F169.
Another 'F169 is the master (for testing) and every now and then, the
communication breaks down.
The master's application is derived from TI app note slaa208
"Interfacing an EEPROM to the MSP430 I2C Module".
I'm implementing a I2C bootloader for the slave device, and the
control flow goes like this:
1a) Master does "ack-polling" to see if the slave is there.
(It puts a start-condition on the bus, followed by the slave address,
followed by a stop condition, until it sees ACK from the slave)
1b) Slave I2C module HW sees its address byte and sends ACK
2a) Master reads slave's status register.
2b) Slave writes its status
Master repeats until the register reads "OK, Slave ready"
3a) Master sends the control code for "write flash block"
3b) Slave enters "write flash block" routine
4a) Master sends a single line of the HEX file
4b) Slave writes data to flash and leaves "write flash block"
routine
5a) Master jumps to 1) if it's not finished
My problem is that the ack-polling sometimes doesn't work. It is not
exactly reproducible, and it seems to depend on things like room
temperature, air moisture, moon phase, etc.
And this error doesn't happen if the master waits a LOOONG time
(almost 100 ms) between steps 5) and 1). (But this is not desirable at
all, and I want to know the real reason for this problem).
When the ack-polling fails, the master sends the correct sequence on
the bus, but the slave doesn't ACK, and this goes on forever.
Ok, it must be the slave, I thought. But when I reset the _master_,
then everything is OK again.
Does this sound familiar to anyone? I don't really know how to further
debug this stuff. I have normal pullups (5K ohms) and if there isn't
lots of traffic, then everything's OK.
Do I have to resort to s/w bit banging? The 'F169 errata sheet
doesn't
mention any bugs in the I2C module, IIRC.
Any ideas/suggestions are very welcome.
TIA,
Patrick
Re: I2C troubleshooting
Started by ●March 8, 2005
Reply by ●March 8, 20052005-03-08
Hi,
I'm developing an I2C slave device based on a MSP430F169.
Another 'F169 is the master (for testing) and every now and then, the
communication breaks down.
The master's application is derived from TI app note slaa208
"Interfacing an EEPROM to the MSP430 I2C Module".
I'm implementing a I2C bootloader for the slave device, and the
control flow goes like this:
1a) Master does "ack-polling" to see if the slave is there.
(It puts a start-condition on the bus, followed by the slave address,
followed by a stop condition, until it sees ACK from the slave)
1b) Slave I2C module HW sees its address byte and sends ACK
2a) Master reads slave's status register.
2b) Slave writes its status
Master repeats until the register reads "OK, Slave ready"
3a) Master sends the control code for "write flash block"
3b) Slave enters "write flash block" routine
4a) Master sends a single line of the HEX file
4b) Slave writes data to flash and leaves "write flash block" routine
5a) Master jumps to 1) if it's not finished
My problem is that the ack-polling sometimes doesn't work. It is not
exactly reproducible, and it seems to depend on things like room
temperature, air moisture, moon phase, etc.
And this error doesn't happen if the master waits a LOOONG time
(almost 100 ms) between steps 5) and 1). (But this is not desirable at
all, and I want to know the real reason for this problem).
When the ack-polling fails, the master sends the correct sequence on
the bus, but the slave doesn't ACK, and this goes on forever.
Ok, it must be the slave, I thought. But when I reset the _master_,
then everything is OK again.
Does this sound familiar to anyone? I don't really know how to further
debug this stuff. I have normal pullups (5K ohms) and if there isn't
lots of traffic, then everything's OK.
Do I have to resort to s/w bit banging? The 'F169 errata sheet doesn't
mention any bugs in the I2C module, IIRC.
Any ideas/suggestions are very welcome.
TIA,
Patrick
I'm developing an I2C slave device based on a MSP430F169.
Another 'F169 is the master (for testing) and every now and then, the
communication breaks down.
The master's application is derived from TI app note slaa208
"Interfacing an EEPROM to the MSP430 I2C Module".
I'm implementing a I2C bootloader for the slave device, and the
control flow goes like this:
1a) Master does "ack-polling" to see if the slave is there.
(It puts a start-condition on the bus, followed by the slave address,
followed by a stop condition, until it sees ACK from the slave)
1b) Slave I2C module HW sees its address byte and sends ACK
2a) Master reads slave's status register.
2b) Slave writes its status
Master repeats until the register reads "OK, Slave ready"
3a) Master sends the control code for "write flash block"
3b) Slave enters "write flash block" routine
4a) Master sends a single line of the HEX file
4b) Slave writes data to flash and leaves "write flash block" routine
5a) Master jumps to 1) if it's not finished
My problem is that the ack-polling sometimes doesn't work. It is not
exactly reproducible, and it seems to depend on things like room
temperature, air moisture, moon phase, etc.
And this error doesn't happen if the master waits a LOOONG time
(almost 100 ms) between steps 5) and 1). (But this is not desirable at
all, and I want to know the real reason for this problem).
When the ack-polling fails, the master sends the correct sequence on
the bus, but the slave doesn't ACK, and this goes on forever.
Ok, it must be the slave, I thought. But when I reset the _master_,
then everything is OK again.
Does this sound familiar to anyone? I don't really know how to further
debug this stuff. I have normal pullups (5K ohms) and if there isn't
lots of traffic, then everything's OK.
Do I have to resort to s/w bit banging? The 'F169 errata sheet doesn't
mention any bugs in the I2C module, IIRC.
Any ideas/suggestions are very welcome.
TIA,
Patrick
Reply by ●March 8, 20052005-03-08
Patrick,
> I'm developing an I2C slave device based on a MSP430F169.
> Another 'F169 is the master (for testing) and every now and then, the
> communication breaks down.
[ snip ]
> Does this sound familiar to anyone? I don't really know how to further
> debug this stuff. I have normal pullups (5K ohms) and if there isn't
> lots of traffic, then everything's OK.
This seems to be a common problem on 169 and 1611s. I'm not sure why it
is, but the hardware I2C does seem to either accentuate existing
problems in I2C interfaces or introduces its own problems (i.e. the
MSP430 hardware I2C may be buggy).
> Do I have to resort to s/w bit banging? The 'F169 errata sheet doesn't
> mention any bugs in the I2C module, IIRC.
I have a board where I can't get hardware I2C to work reliably.
However, software bit-bashed I2C works like a dream. I used TI's own
code for I2C and, unfortunately, came unstuck. My own bit-bashed code,
OTOH, works like a charm on the same hardware using the same port pins.
And it runs just as fast.
In other words, I'd be hard pressed to say that there *is* a problem in
I2C but my experience, and that of others, is that hardware I2C on the
169 isn't completely reliable.
-- Paul.
> I'm developing an I2C slave device based on a MSP430F169.
> Another 'F169 is the master (for testing) and every now and then, the
> communication breaks down.
[ snip ]
> Does this sound familiar to anyone? I don't really know how to further
> debug this stuff. I have normal pullups (5K ohms) and if there isn't
> lots of traffic, then everything's OK.
This seems to be a common problem on 169 and 1611s. I'm not sure why it
is, but the hardware I2C does seem to either accentuate existing
problems in I2C interfaces or introduces its own problems (i.e. the
MSP430 hardware I2C may be buggy).
> Do I have to resort to s/w bit banging? The 'F169 errata sheet doesn't
> mention any bugs in the I2C module, IIRC.
I have a board where I can't get hardware I2C to work reliably.
However, software bit-bashed I2C works like a dream. I used TI's own
code for I2C and, unfortunately, came unstuck. My own bit-bashed code,
OTOH, works like a charm on the same hardware using the same port pins.
And it runs just as fast.
In other words, I'd be hard pressed to say that there *is* a problem in
I2C but my experience, and that of others, is that hardware I2C on the
169 isn't completely reliable.
-- Paul.
Reply by ●March 9, 20052005-03-09
Hi,
--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> This seems to be a common problem on 169 and 1611s. I'm not sure why it
> is, but the hardware I2C does seem to either accentuate existing
> problems in I2C interfaces or introduces its own problems (i.e. the
> MSP430 hardware I2C may be buggy).
Do you know if this applies to the MSP in master or slave mode only,
or both?
Any idea why that is not mentioned in the errata? Any workarounds that
do NOT use bit banging? Perhaps some way to manually reset the I2C
state machine after a timeout?
> My own bit-bashed code,
> OTOH, works like a charm on the same hardware using the same port pins.
> And it runs just as fast.
I guess that slave I2C bit-banging needs interrupts to be reliable.
Unfortunately, I can't use interrupts because I'm writing a
bootloader.
> but my experience, and that of others, is that hardware I2C on the
> 169 isn't completely reliable.
Do you know if there is some information available? This stuff sounds
very vague. Someone at TI must have figured out where and how the
interface breaks down, and how to work around this. I thought that the
H/W I2C interface was one selling point of the F16x's... why should I
use a F16x when the H/W I2C is not working anyway?
Thanks,
Patrick
--- In msp430@msp4..., "Paul Curtis" <plc@r...> wrote:
> This seems to be a common problem on 169 and 1611s. I'm not sure why it
> is, but the hardware I2C does seem to either accentuate existing
> problems in I2C interfaces or introduces its own problems (i.e. the
> MSP430 hardware I2C may be buggy).
Do you know if this applies to the MSP in master or slave mode only,
or both?
Any idea why that is not mentioned in the errata? Any workarounds that
do NOT use bit banging? Perhaps some way to manually reset the I2C
state machine after a timeout?
> My own bit-bashed code,
> OTOH, works like a charm on the same hardware using the same port pins.
> And it runs just as fast.
I guess that slave I2C bit-banging needs interrupts to be reliable.
Unfortunately, I can't use interrupts because I'm writing a
bootloader.
> but my experience, and that of others, is that hardware I2C on the
> 169 isn't completely reliable.
Do you know if there is some information available? This stuff sounds
very vague. Someone at TI must have figured out where and how the
interface breaks down, and how to work around this. I thought that the
H/W I2C interface was one selling point of the F16x's... why should I
use a F16x when the H/W I2C is not working anyway?
Thanks,
Patrick
Reply by ●March 9, 20052005-03-09
I have not yet used the I2C hardware, but one idea. Your host is bit banged?
Try to implement -clock stretching- at your host. Every time after you had
set your clock back to high (at the master) read the clock back. If the
clock is still low - wait. Continue when the clock is going high. The slave
can hold the clock at low level - at any time. Usually this happend (at
uC-slaves) before the slave have to send the next byte or a ACK, but you
should do this in every clock cycle.
What is the background? Your slave is getting a I2C interrupt - you need to
handle it. If your interrupt latency is long it can not answer
immediately. There are 2 ways to handle this for the slave: do not
responding (bad idea) or holding the SCL low. Maybe this kind of clock
stretching is implemented in the slave- but not in the master-mode of the
I2C unit? (you have only 25us per byte at 400kHz, quite short)
Changing the master to a bit banged version is much more simple and reliable
as to write a bit banged slave.
M.
Try to implement -clock stretching- at your host. Every time after you had
set your clock back to high (at the master) read the clock back. If the
clock is still low - wait. Continue when the clock is going high. The slave
can hold the clock at low level - at any time. Usually this happend (at
uC-slaves) before the slave have to send the next byte or a ACK, but you
should do this in every clock cycle.
What is the background? Your slave is getting a I2C interrupt - you need to
handle it. If your interrupt latency is long it can not answer
immediately. There are 2 ways to handle this for the slave: do not
responding (bad idea) or holding the SCL low. Maybe this kind of clock
stretching is implemented in the slave- but not in the master-mode of the
I2C unit? (you have only 25us per byte at 400kHz, quite short)
Changing the master to a bit banged version is much more simple and reliable
as to write a bit banged slave.
M.
Reply by ●March 9, 20052005-03-09
Hi,
--- In msp430@msp4..., Matthias Weingart <msp430@p...> wrote:
> I have not yet used the I2C hardware, but one idea. Your host is bit banged?
No, the master also uses the I2C H/W module.
> Try to implement -clock stretching- at your host. Every time after you had
> set your clock back to high (at the master) read the clock back. If the
> clock is still low - wait.
> Continue when the clock is going high. The slave
> can hold the clock at low level - at any time.
I think that's the default behaviour, and I observed that the slave
does exactly that (when user code doesn't immediately read / write the
data register) and the master recognizes that. So that's probably not
the cause of my problem.
> Changing the master to a bit banged version is much more simple and reliable
> as to write a bit banged slave.
Yes, I will convert the master application to a bit-banged version and
see if it helps. I hope that I can isolate this problem, to see if the
I2C H/W module is broken "only" in master mode, slave mode, or both.
Thanks,
Patrick
--- In msp430@msp4..., Matthias Weingart <msp430@p...> wrote:
> I have not yet used the I2C hardware, but one idea. Your host is bit banged?
No, the master also uses the I2C H/W module.
> Try to implement -clock stretching- at your host. Every time after you had
> set your clock back to high (at the master) read the clock back. If the
> clock is still low - wait.
> Continue when the clock is going high. The slave
> can hold the clock at low level - at any time.
I think that's the default behaviour, and I observed that the slave
does exactly that (when user code doesn't immediately read / write the
data register) and the master recognizes that. So that's probably not
the cause of my problem.
> Changing the master to a bit banged version is much more simple and reliable
> as to write a bit banged slave.
Yes, I will convert the master application to a bit-banged version and
see if it helps. I hope that I can isolate this problem, to see if the
I2C H/W module is broken "only" in master mode, slave mode, or both.
Thanks,
Patrick
Reply by ●March 9, 20052005-03-09
patrick_huesmann wrote:
> Yes, I will convert the master application to a bit-banged version and
> see if it helps. I hope that I can isolate this problem, to see if the
> I2C H/W module is broken "only" in master mode, slave mode, or both.
Let us know what you find. This talk of dodgy I2C hardware in the 169 is
worrying me a little as I'm currently working on a design which will
have three CPUs exchanging lots of data using 400Khz multi-master I2C.
--
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer
> Yes, I will convert the master application to a bit-banged version and
> see if it helps. I hope that I can isolate this problem, to see if the
> I2C H/W module is broken "only" in master mode, slave mode, or both.
Let us know what you find. This talk of dodgy I2C hardware in the 169 is
worrying me a little as I'm currently working on a design which will
have three CPUs exchanging lots of data using 400Khz multi-master I2C.
--
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer
Reply by ●March 9, 20052005-03-09
Hi,
--- In msp430@msp4..., Alex Holden <alex@l...> wrote:
> patrick_huesmann wrote:
> > Yes, I will convert the master application to a bit-banged version and
> > see if it helps. I hope that I can isolate this problem, to see if the
> > I2C H/W module is broken "only" in master mode, slave mode, or both.
>
> Let us know what you find. This talk of dodgy I2C hardware in the 169 is
> worrying me a little as I'm currently working on a design which will
> have three CPUs exchanging lots of data using 400Khz multi-master I2C.
FYI:
Eventually, I've converted the master app to use software-controlled
bit-bang I2C.
I used the routines from the example code file "fet110_8574.s43"
(MSP-FET430x110 Demo - Software I2C Master Interface PCF8574 Read /
Write) which is available on TI's website.
Now the whole upload procedure works reliably, and my problem seems to be gone.
The slave still uses the 'F169 I2C hardware controller.
I don't know if I can safely conclude that the MSP430F16x I2C
controller is broken in master mode, and works in slave mode.
But after more than 3 days of debugging with no result, and then
replacing the Rx/Tx routines with bit bang code just to see that it
immediately works, it looks pretty much like that.
If someone from TI is reading this:
I strongly suggest testing the 'F16x I2C controller with lots of
traffic, and putting the results in the next errata sheet. If the
brokenness of the I2C controller was documented, it'd have saved me
almost a week.
Regards,
Patrick
--- In msp430@msp4..., Alex Holden <alex@l...> wrote:
> patrick_huesmann wrote:
> > Yes, I will convert the master application to a bit-banged version and
> > see if it helps. I hope that I can isolate this problem, to see if the
> > I2C H/W module is broken "only" in master mode, slave mode, or both.
>
> Let us know what you find. This talk of dodgy I2C hardware in the 169 is
> worrying me a little as I'm currently working on a design which will
> have three CPUs exchanging lots of data using 400Khz multi-master I2C.
FYI:
Eventually, I've converted the master app to use software-controlled
bit-bang I2C.
I used the routines from the example code file "fet110_8574.s43"
(MSP-FET430x110 Demo - Software I2C Master Interface PCF8574 Read /
Write) which is available on TI's website.
Now the whole upload procedure works reliably, and my problem seems to be gone.
The slave still uses the 'F169 I2C hardware controller.
I don't know if I can safely conclude that the MSP430F16x I2C
controller is broken in master mode, and works in slave mode.
But after more than 3 days of debugging with no result, and then
replacing the Rx/Tx routines with bit bang code just to see that it
immediately works, it looks pretty much like that.
If someone from TI is reading this:
I strongly suggest testing the 'F16x I2C controller with lots of
traffic, and putting the results in the next errata sheet. If the
brokenness of the I2C controller was documented, it'd have saved me
almost a week.
Regards,
Patrick
Reply by ●March 9, 20052005-03-09
Hi Paul,
Paul Curtis wrote:
> In other words, I'd be hard pressed to say that there *is* a problem
> in I2C but my experience, and that of others, is that hardware I2C on
> the 169 isn't completely reliable.
Is this in your experience only true for Rev. A F169 or also for Rev. B?
Indrek
--
Indrek Rebane | Borthwick-Pignon
Electronics Engineer | Tartu Science Park
Phone: (+372) 7 302 641 | Riia 185, 51014 Tartu
Fax: (+372) 7 383 041 | Estonia
indrek@indr... | www.bps.co.ee
Paul Curtis wrote:
> In other words, I'd be hard pressed to say that there *is* a problem
> in I2C but my experience, and that of others, is that hardware I2C on
> the 169 isn't completely reliable.
Is this in your experience only true for Rev. A F169 or also for Rev. B?
Indrek
--
Indrek Rebane | Borthwick-Pignon
Electronics Engineer | Tartu Science Park
Phone: (+372) 7 302 641 | Riia 185, 51014 Tartu
Fax: (+372) 7 383 041 | Estonia
indrek@indr... | www.bps.co.ee
Reply by ●March 9, 20052005-03-09
