On Thu, Mar 27, 2014 at 2:20 PM, Mike Raines wrote:
> However, I think this works with mush older and
smaller devices that do not have the USCI modules that can be run in I2C or SPI modes....
The USI found on the older/smaller devices actually has an advantage over
the USCI in that it can handle arbitrary word lengths up to 16 bits. It
should not be terribly difficult to re-work this code for the USCI.
Ideally it would be nice to see this re-written with a hardware abstraction
layer so that the same I2C layer can be used for both peripherals, and
possibly even bit-banged I2C.
However, I think this works with mush older and smaller devices that do not
have the USCI modules that can be run in I2C or SPI modes....
Still working on it. Stay tuned...
Regards,
Mike Raines
________________________________
From: m... [mailto:m...] On Behalf Of Peter Johansson
Sent: Thursday, March 27, 2014 9:34 AM
To: m...
Subject: Re: [msp430] TI I2C Example Problems
On Wed, Mar 26, 2014 at 7:15 PM, Martin Bruner
> wrote:
> Since I have seen this issue pop up rather
frequently, do you think it would be a good idea to place some MSP430 I2C code
in a repository, like Github? That way our fellow group members wouldn't
"reinventing the wheel". Someone has indeed already done this for the USI module:
size=1 width="100%" noshade color="#a0a0a0" alignter>
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4354 / Virus Database: 3722/7252 - Release Date: 03/26/14
Reply by Peter Johansson●March 27, 20142014-03-27
On Wed, Mar 26, 2014 at 7:15 PM, Martin Bruner
wrote:
> Since I have seen this issue pop up rather
frequently, do you think it would be a good idea to place some MSP430 I2C code in a repository,
like
Github? That way our fellow group members wouldn't "reinventing the
wheel".
Someone has indeed already done this for the USI module:
Don't know if this is of any use. Below is the ISR that I have been
using
without a problem on an MSP430F5419.
Have fun,
Glenn
#pragma vector = USCI_B0_VECTOR
// I2C A vector
__interrupt void I2CA ( void )
{
switch ( UCB0IV )
{
case 0x00:
break;
case 0x02:
UCB0IFG = UCB0IFG & ~UCALIFG;
break;
case 0x04:
UCB0IFG = UCB0IFG & ~UCNACKIFG;
break;
case 0x06:
UCB0IFG = UCB0IFG & ~UCSTTIFG;
break;
case 0x08:
UCB0IFG = UCB0IFG & ~UCSTPIFG;
TAptr = 0;
break;
case 0x0A:
I2CARx [I2CACnt++] = UCB0RXBUF;
if ( I2CACnt == 256 ) I2CACnt = 0;
break;
case 0x0C:
UCB0TXBUF = TemprA [TAptr++];
if ( TAptr == 2 ) TAptr = 0;
break;
}
}
From: m... [mailto:m...] On Behalf Of
Mike Raines
Sent: Thursday, 27 March 2014 10:57 PM
To: m...
Subject: RE: [msp430] TI I2C Example Problems
Paul,
Thanks again. I had noticed the missing break and fixed it several
times while trying different versions of this TI example code. That's
no
excuse though, for missing it in this latest iteration. It seems if I had
hit case 12 first, I would have seen a msg on the PC from case 12 such as
"ISR:: " before seeing the msg "ISR::default".
I remembered last night while trying to sleep something about the
action of reading the interrupt vector automatically resets it to zero. If
my memory is correct, then reading UCB2IV at any point after the line:
"switch(__even_in_range(UCB2IV,12))" will yield the value 0. I'm going
to
try to capture the value at the top of the ISR for printing. Wish me luck..
Thanks,
Mike Raines
_____
From: m... [mailto:m...] On Behalf Of
Paul Curtis
Sent: Wednesday, March 26, 2014 7:22 PM
To: m...
Subject: Re: [msp430] TI I2C Example Problems
You know there is no break statement at the end of case 12, and that case
flows straight into the default handler!
This is really where you need to invest in something that is designed for
picking up errors like this. PC-lint is a neat piece of software (though I
have reported a couple of bugs in it). Just get into the habit of using it
to check your software, you'll be amazed at what it can pick up because
it
is designed to do that.
I suspect, though am not completely sure, that USBIV==0 indicates that there
is no interrupt pending. You entered case 12, handled the interrupt, the IV
got set to zero, and you fell into the default branch.
- Paul.
On 26 Mar 2014, at 20:57, Mike Raines wrote:
Paul,
Damn, you're good! But you already knew that ( -;)
I first put a msg in each isr case and found I was entering the default
case. I then put a print in the default case and got this output:
***MAIN***
ISR::11
ISR::default
***MAIN***
ISR::11
ISR::default
UCB2IV is: 0
But case 0: is no interrupts. Why didn't the switch statement go
there?
And what does it mean that UCB2IV is 0?
From: m... [mailto:m...] On Behalf Of
Paul Curtis
Sent: Wednesday, March 26, 2014 4:09 PM
To: m...
Subject: Re: [msp430] TI I2C Example Problems
On 26 Mar 2014, at 19:44, Mike Raines wrote:
I was feeling better about this until, suddenly now, sometimes I get no
scope pattern, and the disassembly window shows software stuck on:
Add.b R5, R4
Any ideas? Of course, when this happens, the execution never returns from
the isr.
Suspect you have an interrupt condition that you are not correctly
servicing, and not clearing the flag for it, hence you reenter the interrupt
service routine?
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4354 / Virus Database: 3722/7252 - Release Date: 03/26/14
Reply by Hugo Brunert●March 27, 20142014-03-27
Mike, and others…
Just as standard practice,
Whenever I type the word “case” I also type the word
“break”
And I take that pair and cut and paste it as many times as I will have case
entries.
At the end I type the “default” and “break” pair.
I do this BEFORE I write any single line of code for any of the individual case
statements.
This practice makes me make sure that I never make that mistake of missing a
break, or a default statement.
I do this also for “if” statements, I type the:
If(…)
{
}
And THEN I type whatever code goes inside the squigglies.
Good luck
From: m... [mailto:m...] On Behalf Of Mike Raines
Sent: Thursday, March 27, 2014 7:57 AM
To: m...
Subject: RE: [msp430] TI I2C Example Problems
Paul,
Thanks again. I had noticed the missing break and fixed it several times
while trying different versions of this TI example code. That’s no excuse
though, for missing it in this latest iteration. It seems if I had hit case 12
first, I would have seen a msg on the PC from case 12 such as “ISR:: ” before seeing the msg “ISR::default”.
I remembered last night while trying to sleep something about the action of
reading the interrupt vector automatically resets it to zero. If my memory is
correct, then reading UCB2IV at any point after the line:
“switch(__even_in_range(UCB2IV,12))” will yield the value 0.
I’m going to try to capture the value at the top of the ISR for printing.
Wish me luck….
Thanks,
Mike Raines
________________________________
From: m... [mailto:m...] On Behalf Of Paul Curtis
Sent: Wednesday, March 26, 2014 7:22 PM
To: m...
Subject: Re: [msp430] TI I2C Example Problems
You know there is no break statement at the end of case 12, and that case flows
straight into the default handler!
This is really where you need to invest in something that is designed for
picking up errors like this. PC-lint is a neat piece of software (though I have
reported a couple of bugs in it). Just get into the habit of using it to check
your software, you’ll be amazed at what it can pick up because it is
designed to do that.
I suspect, though am not completely sure, that USBIV==0 indicates that there is
no interrupt pending. You entered case 12, handled the interrupt, the IV got
set to zero, and you fell into the default branch.
— Paul.
On 26 Mar 2014, at 20:57, Mike Raines wrote:
Paul,
Damn, you’re good! But you already knew that ( -;)
I first put a msg in each isr case and found I was entering the default case. I
then put a print in the default case and got this output:
***MAIN***
ISR::11
ISR::default
***MAIN***
ISR::11
ISR::default
UCB2IV is: 0
But case 0: is no interrupts. Why didn’t the switch statement go there?
And what does it mean that UCB2IV is 0?
From: m... [mailto:m...] On Behalf Of Paul Curtis
Sent: Wednesday, March 26, 2014 4:09 PM
To: m...
Subject: Re: [msp430] TI I2C Example Problems
On 26 Mar 2014, at 19:44, Mike Raines wrote:
I was feeling better about this until, suddenly now, sometimes I get no
scope pattern, and the disassembly window shows software stuck on:
Add.b R5, R4
Any ideas? Of course, when this happens, the execution never returns from the
isr.
Suspect you have an interrupt condition that you are not correctly servicing,
and not clearing the flag for it, hence you reenter the interrupt service
routine?
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4354 / Virus Database: 3722/7252 - Release Date: 03/26/14
Reply by Mike Raines●March 27, 20142014-03-27
Paul,
Thanks again. I had noticed the missing break and fixed it several times
while trying different versions of this TI example code. That's no excuse
though, for missing it in this latest iteration. It seems if I had hit case 12
first, I would have seen a msg on the PC from case 12 such as "ISR:: " before seeing the msg "ISR::default".
I remembered last night while trying to sleep something about the action of
reading the interrupt vector automatically resets it to zero. If my memory is
correct, then reading UCB2IV at any point after the line:
"switch(__even_in_range(UCB2IV,12))" will yield the value 0. I'm going to
try to capture the value at the top of the ISR for printing. Wish me
luck....
Thanks,
Mike Raines
________________________________
From: m... [mailto:m...] On Behalf Of Paul Curtis
Sent: Wednesday, March 26, 2014 7:22 PM
To: m...
Subject: Re: [msp430] TI I2C Example Problems
You know there is no break statement at the end of case 12, and that case flows
straight into the default handler!
This is really where you need to invest in something that is designed for
picking up errors like this. PC-lint is a neat piece of software (though I have
reported a couple of bugs in it). Just get into the habit of using it to check
your software, you'll be amazed at what it can pick up because it is
designed to do that.
I suspect, though am not completely sure, that USBIV==0 indicates that there is
no interrupt pending. You entered case 12, handled the interrupt, the IV got
set to zero, and you fell into the default branch.
- Paul.
On 26 Mar 2014, at 20:57, Mike Raines
> wrote:
Paul,
Damn, you're good! But you already knew that ( -;)
I first put a msg in each isr case and found I was entering the default case. I
then put a print in the default case and got this output:
***MAIN***
ISR::11
ISR::default
***MAIN***
ISR::11
ISR::default
UCB2IV is: 0
But case 0: is no interrupts. Why didn't the switch statement go there?
And what does it mean that UCB2IV is 0?
________________________________
From: m... [mailto:m...] On Behalf Of Paul Curtis
Sent: Wednesday, March 26, 2014 4:09 PM
To: m...
Subject: Re: [msp430] TI I2C Example Problems
On 26 Mar 2014, at 19:44, Mike Raines
> wrote:
I was feeling better about this until, suddenly now, sometimes I get no
scope pattern, and the disassembly window shows software stuck on:
Add.b R5, R4
Any ideas? Of course, when this happens, the execution never returns from the
isr.
Suspect you have an interrupt condition that you are not correctly servicing,
and not clearing the flag for it, hence you reenter the interrupt service
routine?
- Paul.
size=1 width="100%" noshade color="#a0a0a0" alignter>
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4354 / Virus Database: 3722/7248 - Release Date: 03/25/14
size=1 width="100%" noshade color="#a0a0a0" alignter>
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4354 / Virus Database: 3722/7252 - Release Date: 03/26/14
Reply by Mike Raines●March 27, 20142014-03-27
Marty,
Althought to some, I'M just a dumba$$ that works in a cubicle, I think
that's an excellent idea. It occurred to me while working on this that
there are probably several million ways to try TI I2C and only one (or maybe 2,
3) THAT WILL WORK. If I get through this, I will contribute.
Thanks,
Mike Raines
________________________________
From: m... [mailto:m...] On Behalf Of Martin Bruner
Sent: Wednesday, March 26, 2014 7:16 PM
To: msp430@yahoogroups. com
Subject: [SPAM] Re: [msp430] TI I2C Example Problems
Importance: Low
Hey everyone,
Since I have seen this issue pop up rather frequently, do you think it would be
a good idea to place some MSP430 I2C code in a repository, like Github? That
way our fellow group members wouldn't "reinventing the wheel".
Thanks,
Marty
From: "David W. Schultz" >
Organization: State of Total Disorganization
Reply-To: "msp430@yahoogroups. com" >
Date: Wednesday, March 26, 2014 5:04 PM
To: "msp430@yahoogroups. com" >
Subject: Re: [msp430] TI I2C Example Problems
On 03/26/2014 01:21 PM, m...@hofferflow.com
wrote: > Hey Folks,
>
> Some of you may remember I just had a problem bit-banging an i2c
> interface to an eeprom, Microchip
>
> 24FC1025. That problem remains unsolved, with IAR and myself continuing
> to work on it, but right now, I am
>
> trying to interface with the eeprom using the TI built-in I2C USCIB2. I
> have been fighting to make a very
>
> simple (I thought) TI example titled "MSP430x54x_uscib0_i2c_08". I have
> minimally altered the example so I
I recently worked at getting the I2C USCI on the G2955 working and it
wasn't easy. I try to record some notes when I work on a project and the
notes for this one start:
"I have been beating my brain against the USCI I2C problem for a while."
I even reverted to my ancient bit banged routines just to verify that
the slave and connections were OK. I did eventually get it to work and
your interrupt code looks very much like mine:
size=1 width="100%" noshade color="#a0a0a0" alignter>
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4354 / Virus Database: 3722/7252 - Release Date: 03/26/14
Reply by Paul Curtis●March 26, 20142014-03-26
You know there is no break statement at the end of case 12, and that case flows
straight into the default handler!
This is really where you need to invest in something that is designed for
picking up errors like this. PC-lint is a neat piece of software (though I have
reported a couple of bugs in it). Just get into the habit of using it to check
your software, youll be amazed at what it can pick up because it is designed to
do that.
I suspect, though am not completely sure, that USBIV==0 indicates that there is
no interrupt pending. You entered case 12, handled the interrupt, the IV got
set to zero, and you fell into the default branch.
Paul.
On 26 Mar 2014, at 20:57, Mike Raines wrote:
> Paul,
>
> Damn, youre good! But you already knew that ( -;)
> I first put a msg in each isr case and found I was entering the default case.
I then put a print in the default case and got this output:
>
>
> ***MAIN***
> ISR::11
> ISR::default
>
>
>
>
>
> ***MAIN***
> ISR::11
> ISR::default
> UCB2IV is: 0
>
> But case 0: is no interrupts. Why didnt the switch statement go there? And
what does it mean that UCB2IV is 0?
>
> Thanks again,
> Mike Raines
> #pragma vector = USCI_B2_VECTOR
> __interrupt void USCI_B2_ISR(void)
> {
> switch(__even_in_range(UCB2IV,12))
> {
> case 0:
> TxBuffer("ISR::No interrupts", 20, 1);
> break; // Vector 0: No interrupts
> case 2:
> TxBuffer("ISR::ALIFG", 20, 1);
> break; // Vector 2: ALIFG
> case 4:
> TxBuffer("ISR::NACKIFG", 20, 1);
> break; // Vector 4: NACKIFG
> case 6:
> TxBuffer("ISR::STTIFG", 20, 1);
> break; // Vector 6: STTIFG
> case 8:
> TxBuffer("ISR::STPIFG", 20, 1);
> break; // Vector 8: STPIFG
> case 10:
> TxBuffer("ISR::RXIFG", 20, 1);
> break; // Vector 10: RXIFG
> case 12: // Vector 12: TXIFG
>
>
> if (TXByteCtr) // Check TX byte counter
> {
> #if 1 // print out??
> sprintf(outBuf, "ISR::%X", *PTxData);
> TxBuffer(outBuf, 10, 1);
> #endif // print out??
>
> DelayI2cEeprom();
> UCB2TXBUF = *PTxData++; // Load TX buffer
> TXByteCtr--; // Decrement TX byte counter
> }
> else
> {
> UCB2CTL1 |= UCTXSTP; // I2C stop condition
> UCB2IFG &= ~UCTXIFG; // Clear USCI_B2 TX int flag
> __bic_SR_register_on_exit(LPM0_bits); // Exit LPM0
> }
> default:
> TxBuffer("ISR::default", 20, 1);
> sprintf(outBuf, "UCB2IV is: %X", UCB2IV);
> TxBuffer(outBuf, 30, 1);
> break;
> }
> }
>
> From: m... [mailto:m...] On Behalf Of Paul Curtis
> Sent: Wednesday, March 26, 2014 4:09 PM
> To: m...
> Subject: Re: [msp430] TI I2C Example Problems
>
>
>
>
> On 26 Mar 2014, at 19:44, Mike Raines wrote:
> I was feeling better about this until, suddenly now, sometimes I get no
scope pattern, and the disassembly window shows software stuck on:
> Add.b R5, R4
>
> Any ideas? Of course, when this happens, the execution never returns from the
isr.
>
> Suspect you have an interrupt condition that you are not correctly servicing,
and not clearing the flag for it, hence you reenter the interrupt service
routine?
>
> Paul.
>
> size=1 width="100%" noshade color="#a0a0a0" alignter>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4354 / Virus Database: 3722/7248 - Release Date: 03/25/14
>
Reply by Martin Bruner●March 26, 20142014-03-26
Hey everyone,
Since I have seen this issue pop up rather frequently, do you think it would
be a good idea to place some MSP430 I2C code in a repository, like Github?
That way our fellow group members wouldn't "reinventing the wheel".
Thanks,
Marty
From: "David W. Schultz"
Organization: State of Total Disorganization
Reply-To: "msp430@yahoogroups. com"
Date: Wednesday, March 26, 2014 5:04 PM
To: "msp430@yahoogroups. com"
Subject: Re: [msp430] TI I2C Example Problems
On 03/26/2014 01:21 PM, m...@hofferflow.com wrote: > Hey Folks,
>
> Some of you may remember I just had a problem bit-banging an i2c
> interface to an eeprom, Microchip
>
> 24FC1025. That problem remains unsolved, with IAR and myself continuing
> to work on it, but right now, I am
>
> trying to interface with the eeprom using the TI built-in I2C USCIB2. I
> have been fighting to make a very
>
> simple (I thought) TI example titled "MSP430x54x_uscib0_i2c_08". I have
> minimally altered the example so I
I recently worked at getting the I2C USCI on the G2955 working and it
wasn't easy. I try to record some notes when I work on a project and the
notes for this one start:
"I have been beating my brain against the USCI I2C problem for a while."
I even reverted to my ancient bit banged routines just to verify that
the slave and connections were OK. I did eventually get it to work and
your interrupt code looks very much like mine:
Reply by "David W. Schultz"●March 26, 20142014-03-26
On 03/26/2014 01:21 PM, m...@hofferflow.com wrote: > Hey Folks,
>
> Some of you may remember I just had a problem bit-banging an i2c
> interface to an eeprom, Microchip
>
> 24FC1025. That problem remains unsolved, with IAR and myself continuing
> to work on it, but right now, I am
>
> trying to interface with the eeprom using the TI built-in I2C USCIB2. I
> have been fighting to make a very
>
> simple (I thought) TI example titled "MSP430x54x_uscib0_i2c_08". I have
> minimally altered the example so I
I recently worked at getting the I2C USCI on the G2955 working and it
wasn't easy. I try to record some notes when I work on a project and the
notes for this one start:
"I have been beating my brain against the USCI I2C problem for a while."
I even reverted to my ancient bit banged routines just to verify that
the slave and connections were OK. I did eventually get it to work and
your interrupt code looks very much like mine:
