Thanks.
I think i'll start with simple Ports (Px.y) and if it works i'll use them as SPI
Ports (with the SFR).


> "SIMO" (Slave In, Master Out) is data out and "SIMI" is data in (with
>respect to the processor). I don't know the specifics of the MMC but I
>would bet that DataIn and DataOut are with respect to that card. If
>this is the case, you would connect SIMO to DataIn and SIMI to DataOut.
>
> STE is a bit more complex. It is the "Slave Transmit Enable" and is NOT
>the same as a chip select. You may need to implement the CS
>independently (in software).
>
>Jim Wagner
>
>--- nobodyo@... wrote:
>> Hi,
>>
>> i want to use a MultiMediaCard (MMC) with the UART of a MSP430 but i
>> could not find all ports.
>> The MMC has CS, DataIn, Clk and DataOut while the UART has SIM0, STE,
>> SOMI and SCLK.
>> It's clear that i have to take SCLK as Clk but what do i have to
>> connect to CS, DataIn and DataOut?

--- In msp430@yahoogroups.com, "byrant  b" <byrant@r...> wrote:
  >    But not aniticipated issue of board getting reset after a time
> period of 1200-1300 msec occurs constantly (sets a barrier of
> sending only 5 messages sequentially). Suspecting Watchdog petting
> and Timer ISR i carried out several tests but nothing solved the
> issue.

Here's another idea --- are you ** sure ** that you're clearing the
watchdog properly? I ask because there are some subtleties with it,
and if you write something like this in C:

WDTCTL = (WDTCTL & 0x00FF) + WDTPW + WDTCNTCL

(which will preserve your watchdog configuration while clearing the
wdt itself) your compiler had better generate something like this:

	 mov &0x120,r12
	 and #0xff,r12
	 add #0x5a08,r12
	 mov r12,&0x120

and not like this:

	 mov     &0x120,r12
	 and     #0xff,r12
	 add     #0x5a00,r12
	 mov     r12,&0x120
	 add     #8,&0x120

In the latter case, you'll get a reset on the last instruction.

--Andrew

Andrew,

> --- In msp430@yahoogroups.com, "byrant  b" <byrant@r...> wrote:
>  >    But not aniticipated issue of board getting reset after a time
> > period of 1200-1300 msec occurs constantly (sets a barrier of
> > sending only 5 messages sequentially). Suspecting Watchdog petting
> > and Timer ISR i carried out several tests but nothing solved the
> > issue.
>
> Here's another idea --- are you ** sure ** that you're
> clearing the watchdog properly? I ask because there are some
> subtleties with it, and if you write something like this in C:
>
> WDTCTL = (WDTCTL & 0x00FF) + WDTPW + WDTCNTCL
>
> (which will preserve your watchdog configuration while
> clearing the wdt itself) your compiler had better generate
> something like this:
>
>  mov &0x120,r12
>  and #0xff,r12
>  add #0x5a08,r12
>  mov r12,&0x120
>
> and not like this:
>
>  mov     &0x120,r12
>  and     #0xff,r12
>  add     #0x5a00,r12
>  mov     r12,&0x120
>  add     #8,&0x120
>
> In the latter case, you'll get a reset on the last instruction.

You can only be sure that your compiler will *not* generate the second
instance is if you declare WDTCTL volatile.  Unfortunately, there are
MSP430 compilers that just ignore volatile when the going gets tough and
do not respect the rules--which is a shame.  May not bite now, but it
sure will at some point...

Consider the case of a write-only register and a shadow value:

   shadow_register = write_only_port = a_new_value;

Unfortunately, some compilers will write a_new_value to the
write_only_port, read the write_only_port, and write bollocks to the
shadow_register.  There are even worse crimes that some MSP430 compilers
are guilty of with volatile.  :-(

-- Paul.

At 10:47 PM 3/4/2003 +0000, Paul Curtis wrote:
>Andrew,
>
> > --- In msp430@yahoogroups.com, "byrant  b" <byrant@r...> wrote:
> >  >    But not aniticipated issue of board getting reset after a time
> > > period of 1200-1300 msec occurs constantly (sets a barrier of
> > > sending only 5 messages sequentially). Suspecting Watchdog petting
> > > and Timer ISR i carried out several tests but nothing solved the
> > > issue.
> >
> > Here's another idea --- are you ** sure ** that you're
> > clearing the watchdog properly? I ask because there are some
> > subtleties with it, and if you write something like this in C:
> >
> > WDTCTL = (WDTCTL & 0x00FF) + WDTPW + WDTCNTCL
> >
> > (which will preserve your watchdog configuration while
> > clearing the wdt itself) your compiler had better generate
> > something like this:
> >
> >       mov     &0x120,r12
> >       and     #0xff,r12
> >       add     #0x5a08,r12
> >       mov     r12,&0x120
> >
> > and not like this:
> >
> >       mov     &0x120,r12
> >       and     #0xff,r12
> >       add     #0x5a00,r12
> >       mov     r12,&0x120
> >       add     #8,&0x120
> >
> > In the latter case, you'll get a reset on the last instruction.
>
>You can only be sure that your compiler will *not* generate the second
>instance is if you declare WDTCTL volatile.  Unfortunately, there are
>MSP430 compilers that just ignore volatile when the going gets tough and
>do not respect the rules--which is a shame.  May not bite now, but it
>sure will at some point...

I am guilty on this one. I need to add some rules about not operating on
directly &<io registers>. Also I need to see why the constants are not
folded totally.


>Consider the case of a write-only register and a shadow value:
>
>   shadow_register = write_only_port = a_new_value;
>
>Unfortunately, some compilers will write a_new_value to the
>write_only_port, read the write_only_port, and write bollocks to the
>shadow_register.  There are even worse crimes that some MSP430 compilers
>are guilty of with volatile.  :-(

Ah yes, many a-hours are spent on the GCC mailing list on this. Those
people are soooo pedantic :-) (just do the right thing for your customers,
damn it, oh wait, GCC is "free" so there is no customers per se...)

// richard <http://www.imagecraft.com>
<http://www.dragonsgate.net/mailman/listinfo>
On-line orders, support, and listservers available on web site.
[ For technical support on ImageCraft products, please include all previous
replies in your msgs. ]

--- In msp430@yahoogroups.com, "Richard F. Man" <richard@i...> wrote:
> I am guilty on this one. I need to add some rules about not
operating on
> directly &<io registers>. Also I need to see why the constants are
not
> folded totally.

Wow, Richard, you get my "forthright and honest in a public forum
award" for today. My hat's off to you!

I purposly obfuscated the assembly listing so that it did not point to
ICC430 -- ICC430 uses R13 and lists constants in decimal format, for
example, in this little snippet.

BTW, I meant the post primarily as a general heads-up to point out
that there is the sometimes the potential for unwanted artifacts in
translating C to assembly, as Paul rightly pointed out. With something
as touchy as the MSP430's watchdog timer reset procedure, it may make
sense to inspect the compiler's output to ensure that the "rules for
reset" are observed by the instructions generated.

Anyway, it's very reassuring to see that despite the occasional bugs
we identify in various compilers, the "people behind the tools" like
Richard, Paul and Michel are quick to acknowledge a problem and
provide a fix in short time.

--Andrew

Hi Andrew,

> --- In msp430@yahoogroups.com, "Richard F. Man" <richard@i...> wrote:
> > I am guilty on this one. I need to add some rules about not
> operating on
> > directly &<io registers>. Also I need to see why the constants are
> not
> > folded totally.
>
> Wow, Richard, you get my "forthright and honest in a public
> forum award" for today. My hat's off to you!
>
> I purposly obfuscated the assembly listing so that it did not
> point to ICC430 -- ICC430 uses R13 and lists constants in
> decimal format, for example, in this little snippet.

Actually, other compilers are guilty of not respecting volatile and the
data item to which they point.  It *really* gets fun when you have
volatile bit fields, as compilers are all too quick to generate code
which doesn't actually work as required.  Shame, but true.  One compiler
even barfs, as a customer pointed out recently.  Nobody is immune from
compiler problems, as I know only too well.

What I can say, though, I've only stepped on one bug in the IAR v2.09B
beta compiler, which is fairly good going.  But then, it is a beta, and
perhaps it might even be cleared up before they release.  Oh, and it
does generate good code, so we all need to pull our socks up.  Shame
there's still no 64-bit floating point or 64-bit integers--you need a
much cheaper compiler for that.  ;-)

-- Paul.

At 03:10 AM 3/5/2003 +0000, Paul Curtis wrote:
>What I can say, though, I've only stepped on one bug in the IAR v2.09B
>beta compiler, which is fairly good going.  But then, it is a beta, and
>perhaps it might even be cleared up before they release.  Oh, and it
>does generate good code, so we all need to pull our socks up.  Shame
>there's still no 64-bit floating point or 64-bit integers--you need a
>much cheaper compiler for that.  ;-)
>
>-- Paul.
>...

We have now gotten a 64 bit FP lib for the AVR, and despite many existing
AVR users, only one person/company says they are interested!!!

We may still put it in for the PRO version for the ICC430 as well, but it
probably is not a big draw.... I can be wrong though.


// richard <http://www.imagecraft.com>
<http://www.dragonsgate.net/mailman/listinfo>
On-line orders, support, and listservers available on web site.
[ For technical support on ImageCraft products, please include all previous
replies in your msgs. ]

Hi groups,
    Thanks a lot for your valuable feedbacks. Exploring more deeper
my issue drifts me to suspect that UART0 is undergoing some
unexpected behaviour.
Iam pasting my test polling UART0 code below
(No interrupt enables and ISR only polling mode)
##################################################
void App_Main(void)
{
    unsigned int wIdx,wCount=0;
    unsigned char bRetries;

    WDTCTL = WDTPW + WDTHOLD;             // Stop WDT

    //My boards port initialization
    P1DIR  = 0xFF;
    P2DIR  = 0;
    P3SEL  = BIT4 | BIT5 | BIT6 | BIT7;
    P3DIR  = BIT0 | BIT2 | BIT3|BIT4;
    P4DIR  = 0xFF;
    P5DIR  = BIT0 | BIT1 | BIT2 | BIT3 | BIT5 | BIT6 | BIT7;
    P6DIR  = 0xFF;

    //My clocking intialization
    //**************************
    BCSCTL1 = RSEL2;
    _BIS_SR( OSCOFF );

   //- Wait for clock to settle then check that crystal clock is
good
     do
     {
        IFG1 &= ~OFIFG;
        for ( wIdx = 0; wIdx < 1024; wIdx++ )
        {
           // delay to let clock stablize
        }
        bRetries++;
     }
     while( ( IFG1 & OFIFG ) && ( bRetries < 3 ) );
     //    - Switch to use crystal clock if OK
     if (!( IFG1 & OFIFG ))
     {
        // Crystal clock is good - use it
        //    - SMCLK: use XT2CLK, Divide by 8
        //    - MCLK: use XT2CLK, Divide by 1
        //    - ACLK: not active

        BCSCTL2 = DIVS0 | DIVS1 | SELS | SELM1;
     }
     else
       return;
    //**************************

    WDTCTL = WDTPW | WDTCNTCL; //trigger watchdog

    UCTL0 &=~ SWRST;
    UCTL0 = CHAR;                         // 8-bit character
    U0TCTL |= SSEL0 | SSEL1;
    UBR00 = 0x60;
    UBR10 = 0x00;
    UMCTL0 = 0x00;
    U0RCTL = 0x00;
    U0TCTL &= ~( CKPH | CKPL | URXSE | TXWAKE | STC );
    ME1 |= (UTXE0|URXE0);    // Enable USART0 TXD/RXD
    // Selected 8-bit character mode...Override port 3 setting
again
    P3SEL |= 0x30; //BIT5+BIT4; // Pin P3.5 and P3.4 and P3.3 used
by
    P3DIR |= 0x10; // BIT4; // Pin P3.4 is output
    _EINT();                              // Enable global
interrupt

     WDTCTL = WDTPW | WDTCNTCL;

     memset((void *)&abTx,0,sizeof(abTx));

     memcpy((void *)&abTx[0],"ABCDEFGHI",9) ;

    GNCIMsgPtr = (unsigned char *) &abTx[0];

    GbNCIBytesToSend = 9;

    // Enable Transmitter

    NCI_TX_ENABLE;

     while(--GbNCIBytesToSend>0)
     {
            WDTCTL = WDTPW | WDTCNTCL;
 	   while((IFG1 & UTXIFG0) == 0 )
 	   {
 	    WDTCTL = WDTPW | WDTCNTCL;
 	   }
 	   U0TXBUF = *GNCIMsgPtr++;
      }
}

##################################################

There is was a unexpected output. I observed the sequence of bytes
"ABCDEFGHI" getting tranmitted recursively eventhough ive issued
only a single call. Suspecting  a board reset i pinned the /RST
pin to the CRO and observed it was always high and didnt go for
reset.

Hence now my issue is i cant interpret whats this kind of
behaviour of UART0. Is there any intialization iam missing or any
bug in my driver? Iam using IAR embedded workbench compiler for
MSP430.
Has anyone observed similar behaviour? How to overcome this
issue?


Thanks & Regards




On Wed, 05 Mar 2003 aekalman wrote :
>--- In msp430@yahoogroups.com, "Richard F. Man" <richard@i...>
>wrote:
> > I am guilty on this one. I need to add some rules about not
>operating on
> > directly &<io registers>. Also I need to see why the constants
>are
>not
> > folded totally.
>
>Wow, Richard, you get my "forthright and honest in a public
>forum
>award" for today. My hat's off to you!
>
>I purposly obfuscated the assembly listing so that it did not
>point to
>ICC430 -- ICC430 uses R13 and lists constants in decimal format,
>for
>example, in this little snippet.
>
>BTW, I meant the post primarily as a general heads-up to point
>out
>that there is the sometimes the potential for unwanted artifacts
>in
>translating C to assembly, as Paul rightly pointed out. With
>something
>as touchy as the MSP430's watchdog timer reset procedure, it may
>make
>sense to inspect the compiler's output to ensure that the "rules
>for
>reset" are observed by the instructions generated.
>
>Anyway, it's very reassuring to see that despite the occasional
>bugs
>we identify in various compilers, the "people behind the tools"
>like
>Richard, Paul and Michel are quick to acknowledge a problem and
>provide a fix in short time.
>
>--Andrew
>
>
>To unsubscribe from the msp430 group, send an email to:
>msp430-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to
>http://docs.yahoo.com/info/terms/
>
>

I an integer that I want to be located in flash memory on the MSP430F1121
chip. But I have a problem making this work:


     #define ONBOARD_FLASH_ADDRESS 0x1080
...
     uint *ptrToCounter  = (uint *) ONBOARD_FLASH_ADDRESS;
	 *ptrToCounter =

     FCTL2 = FWKEY + FSSEL0 + FN0;
     while ( FCTL3 & BUSY);
     FCTL3 = FWKEY;
     FCTL1 = FWKEY + WRT;
     *ptrToCounter = absoluteFlashPointer;
     FCTL1 = FWKEY;
     FCTL3 = FWKEY + LOCK;
     while ( ! (FCTL3 & WAIT) );
     absoluteFlashPointer = *ptrToCounter;

When I read back the pointers are not the same.

Jardar

Have a look at SLAA103, it includes C code to program flash.

Al

Jardar Johannes Maatje wrote:
>
> I an integer that I want to be located in flash memory on the
> MSP430F1121
> chip. But I have a problem making this work:
>
>     #define ONBOARD_FLASH_ADDRESS 0x1080
> ...
>     uint *ptrToCounter  = (uint *) ONBOARD_FLASH_ADDRESS;
>       *ptrToCounter =
>
>     FCTL2 = FWKEY + FSSEL0 + FN0;
>     while ( FCTL3 & BUSY);
>     FCTL3 = FWKEY;
>     FCTL1 = FWKEY + WRT;
>     *ptrToCounter = absoluteFlashPointer;
>     FCTL1 = FWKEY;
>     FCTL3 = FWKEY + LOCK;
>     while ( ! (FCTL3 & WAIT) );
>     absoluteFlashPointer = *ptrToCounter;
>
> When I read back the pointers are not the same.
>
> Jardar
>
>                    Yahoo! Groups Sponsor
>                        ADVERTISEMENT
>
>
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Jardar -

An important thing to remember: you can change flash bits in only one
direction. I believe that you can only change a  1 to a 0. If you need
to go the other way, your ONLY option is to clear the whole segment!

Jim Wagner

--- Jardar Johannes Maatje <maatje@...> wrote:
> I an integer that I want to be located in flash memory on the
> MSP430F1121
> chip. But I have a problem making this work:
>
>
>     #define ONBOARD_FLASH_ADDRESS 0x1080
> ...
>     uint *ptrToCounter  = (uint *) ONBOARD_FLASH_ADDRESS;
>  *ptrToCounter =
>
>     FCTL2 = FWKEY + FSSEL0 + FN0;
>     while ( FCTL3 & BUSY);
>     FCTL3 = FWKEY;
>     FCTL1 = FWKEY + WRT;
>     *ptrToCounter = absoluteFlashPointer;
>     FCTL1 = FWKEY;
>     FCTL3 = FWKEY + LOCK;
>     while ( ! (FCTL3 & WAIT) );
>     absoluteFlashPointer = *ptrToCounter;
>
> When I read back the pointers are not the same.
>
> Jardar
>
>


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Hi All,

I've got a question. I'm using the F149 and I've got the code as
hereunder:

typedef struct KbRec {
             int ID;
// the ID of the button ex. 0xd310 ie layout D3 button 10
             BYTE Resp;                                          //
indicates if we need to send a response
             KbProc *Server;                                 // pointer
to the function that shoud be activated
} KbRec;

#pragma memory=constseg(FKBSTRUCT)
KbRec Keys[KbNrOfKeys];    // struct will be stored in Flash @ $1B00
#pragma memory=default

void MSPEraseSegment(uint seg){
    uchar *ptr;                         // Flash pointer.
    ptr=(uchar*)seg;
    FCTL1=FWKEY|ERASE;                  // set erase flag.
    FCTL3=FWKEY;                        // Clear Lock bit.
    *ptr=0;                             // Dummy write to erase Flash
segment.
    FCTL3=FWKEY|LOCK;                   // Reset LOCK en WRT bit.
}

and in the xcl file i've got:

//  Information memory (FLASH)
-Z(CODE)INFO=1000-10FF
-Z(CODE)FSTRUCT=1100-1CFF
-Z(CODE)FKBSTRUCT=1B00-1DFF

//  Main memory (FLASH)
-Z(CODE)CODE,CONST,CSTR,CDATA0,CCSTR=1E00-FFDF

Now the problem is that other if i say MSPEraseSegment(struct1); //
struct1 is defined to be in the FSTRUCT area
The appropriate segment get erased. But when I say
MSPEraseSegment((int)Keys); // clear sement since new data has arrived.


only a part of the segment get's erased How can this be?? Am I
overlooking something here??
B.t.w:
.map file :

SEGMENT              SPACE   START ADDRESS    END ADDRESS      SIZE
TYPE  ALIGN
=======              =====   =============    ===========      ====
====  =====
UDATA0                                0200 - 077F               580
rel    1
IDATA0                                 0780 - 07E5                66
rel    1
ECSTR                                   07E6                         rel
1
CSTACK                                0A00                         rel
1
FSTRUCT                              1100 - 1277               178   rel
1
FKBSTRUCT                        1B00 - 1C67               168   rel
1
CODE                                    1E00 - 70DF              52E0
rel    1
CONST                                 70E0 - 7166                87
rel    1
CSTR                                     7168 - 7631               4CA
rel    1
CDATA0                               7632 - 7697                66   rel
1
CCSTR                                  7698                         rel
1
INTVEC                                FFE0 - FFFF                20
com    1

                 ****************************************
                 *                                      *
                 *        END OF CROSS REFERENCE        *
                 *                                      *
                 ****************************************

  23 447 bytes of CODE memory
   1 510 bytes of DATA memory

thanks
Martijn Broens



[Non-text portions of this message have been removed]

If that's your entire program, then you should expect to see
the program endlessly repeat - what do you think happens when
your main() returns? It gets re-executed. Try adding

for(;;);

to the end of the program.

As a general rule, every embedded program needs some kind of endless loop
in main(). There's no sense to an embedded application exiting or returning
from main because there's nowhere to exit to.


--
Clyde Stubbs                     |            HI-TECH Software
Email: clyde@...          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clyde@...   | AUS: +61 7 3552 7777 +61 7 3552 7778
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

Hi.
I am having some trouble getting the SPI to work. I am using UART0.
The MSP430F149 is the master in 3 wire mode.
In this example, the chip select of the slave chip is on P2.2.

I am initializing the UART like this:
   ME1 |= USPIE0;                        // Enable USART0 SPI mode
   UTCTL0 = SSEL1+SSEL0+STC;             // SMCLK, 3-pin mode
   UCTL0 = CHAR+SYNC+MM;                 // 8-bit SPI Master **SWRST**
   UBR00 = 0x02;                         // UCLK/2
   UBR10 = 0x00;                         // 0
   UMCTL0 = 0x00;                        // no modulation
   P3SEL |= 0x0E;                        // P3.1-3 SPI option select
   P2DIR |= 0x04;                        // P2.2 output direction
   P2OUT |= 0x04;
   _EINT();                              // Enable interrupts

Then I send a 2 byte packet like this:
   while ((IFG1 & UTXIFG0) == 0);        // USART0 TX buffer ready?
   P2OUT &= ~0x04;                       // Latch
   TXBUF0 = 0x01;
   while ((IFG1 & UTXIFG0) == 0);        // USART0 TX buffer ready?
   TXBUF0 = 0x00;
   P2OUT |= 0x04;

Hanging a scope on the CLK line shows a strange pattern of ups and
downs, nothing like a clock. The weird pattern is the same no matter
what I send. Hanging the scope on the data line shows a pulse, that
looks nothing like the data.

It does this whether I use my board or the FET430F140 demo board. I
have also tried it with the DCO and with an external high speed
crystal.

Any help would be greatly appreciated.
Thanks,
-mat

Not according to SLAA130. This states that FLASH reprogramming is
possible at a byte level. ie erase/program as a cycle.

Al

James Wagner wrote:
>
> Jardar -
>
> An important thing to remember: you can change flash bits in only one
> direction. I believe that you can only change a  1 to a 0. If you need
> to go the other way, your ONLY option is to clear the whole segment!
>
> Jim Wagner
>
> --- Jardar Johannes Maatje <maatje@...> wrote:
> > I an integer that I want to be located in flash memory on the
> > MSP430F1121
> > chip. But I have a problem making this work:
> >
> >
> >     #define ONBOARD_FLASH_ADDRESS 0x1080
> > ...
> >     uint *ptrToCounter  = (uint *) ONBOARD_FLASH_ADDRESS;
> >       *ptrToCounter =
> >
> >     FCTL2 = FWKEY + FSSEL0 + FN0;
> >     while ( FCTL3 & BUSY);
> >     FCTL3 = FWKEY;
> >     FCTL1 = FWKEY + WRT;
> >     *ptrToCounter = absoluteFlashPointer;
> >     FCTL1 = FWKEY;
> >     FCTL3 = FWKEY + LOCK;
> >     while ( ! (FCTL3 & WAIT) );
> >     absoluteFlashPointer = *ptrToCounter;
> >
> > When I read back the pointers are not the same.
> >
> > Jardar
> >
> >
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
>
>                    Yahoo! Groups Sponsor
>                        ADVERTISEMENT
>
>
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

No, I think you'll find that this is not a correct interpretation.  Yes,
you can write at the bye or word level, but you can only overprogram a
byte a fixed number of times before you need to erase it, *and* you can
only change bits from 1 to 0 as James wrote.

-- Paul.

> -----Original Message-----
> From: onestone [mailto:onestone@...]
> Sent: 06 March 2003 01:04
> To: msp430@yahoogroups.com
> Subject: Re: [msp430] Writing to flash
>
>
> Not according to SLAA130. This states that FLASH
> reprogramming is possible at a byte level. ie erase/program
> as a cycle.
>
> Al
>
> James Wagner wrote:
> >
> > Jardar -
> >
> > An important thing to remember: you can change flash bits
> in only one
> > direction. I believe that you can only change a  1 to a 0.
> If you need
> > to go the other way, your ONLY option is to clear the whole segment!
> >
> > Jim Wagner
> >
> > --- Jardar Johannes Maatje <maatje@...> wrote:
> > > I an integer that I want to be located in flash memory on the
> > > MSP430F1121 chip. But I have a problem making this work:
> > >
> > >
> > >     #define ONBOARD_FLASH_ADDRESS 0x1080
> > > ...
> > >     uint *ptrToCounter  = (uint *) ONBOARD_FLASH_ADDRESS;
> > >       *ptrToCounter =
> > >
> > >     FCTL2 = FWKEY + FSSEL0 + FN0;
> > >     while ( FCTL3 & BUSY);
> > >     FCTL3 = FWKEY;
> > >     FCTL1 = FWKEY + WRT;
> > >     *ptrToCounter = absoluteFlashPointer;
> > >     FCTL1 = FWKEY;
> > >     FCTL3 = FWKEY + LOCK;
> > >     while ( ! (FCTL3 & WAIT) );
> > >     absoluteFlashPointer = *ptrToCounter;
> > >
> > > When I read back the pointers are not the same.
> > >
> > > Jardar
> > >
> > >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> >
> >                    Yahoo! Groups Sponsor
> >                        ADVERTISEMENT
> >
> >
> >
> > To unsubscribe from the msp430 group, send an email to:
> > msp430-unsubscribe@egroups.com
> >
> > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~--> Get 128 Bit SSL Encryption!
> http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA> /CFFolB/TM
>
>
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
>

The garbage data was because of some screwy clock settings.
Got that all running nicely.
And corrected the problem where I latched the CS line after putting
the byte in the buffer, when I should have waited until the byte was
actually sent.
All works well now.
-mat

--- In msp430@yahoogroups.com, "matastrophic" <matastrophic@y...>
wrote:
> Hi.
> I am having some trouble getting the SPI to work. I am using UART0.
> The MSP430F149 is the master in 3 wire mode.
> In this example, the chip select of the slave chip is on P2.2.
>
> I am initializing the UART like this:
>   ME1 |= USPIE0;                        // Enable USART0 SPI mode
>   UTCTL0 = SSEL1+SSEL0+STC;             // SMCLK, 3-pin mode
>   UCTL0 = CHAR+SYNC+MM;                 // 8-bit SPI Master
**SWRST**
>   UBR00 = 0x02;                         // UCLK/2
>   UBR10 = 0x00;                         // 0
>   UMCTL0 = 0x00;                        // no modulation
>   P3SEL |= 0x0E;                        // P3.1-3 SPI option select
>   P2DIR |= 0x04;                        // P2.2 output direction
>   P2OUT |= 0x04;
>   _EINT();                              // Enable interrupts
>
> Then I send a 2 byte packet like this:
>   while ((IFG1 & UTXIFG0) == 0);        // USART0 TX buffer ready?
>   P2OUT &= ~0x04;                       // Latch
>   TXBUF0 = 0x01;
>   while ((IFG1 & UTXIFG0) == 0);        // USART0 TX buffer ready?
>   TXBUF0 = 0x00;
>   P2OUT |= 0x04;
>
> Hanging a scope on the CLK line shows a strange pattern of ups and
> downs, nothing like a clock. The weird pattern is the same no
matter
> what I send. Hanging the scope on the data line shows a pulse,
that
> looks nothing like the data.
>
> It does this whether I use my board or the FET430F140 demo board.
I
> have also tried it with the DCO and with an external high speed
> crystal.
>
> Any help would be greatly appreciated.
> Thanks,
> -mat

All,

> What I can say, though, I've only stepped on one bug in the
> IAR v2.09B beta compiler, which is fairly good going.  But
> then, it is a beta, and perhaps it might even be cleared up
> before they release.

Oh, make that two bugs and a way to make the compiler snooze.  Tried to
compile a 150 line program, left it going for over an hour, came back,
300MB of memory chewed by ICC430 and still no output, so killed the
compiler.  Of course, it's only a beta, but I guess that these bugs
won't be cleared up before release.  And as you know, IAR just love
comparing Beta quality compilers in their advertising material and in
side chats, so I thought I'd give them a dose of their own medicine. ;-)

-- Paul.

Thanks all of you, everything si fine now. Did not know that it was only
possible to set it from 1 to 0.

Jardar

> No, I think you'll find that this is not a correct interpretation.  Yes,
> you can write at the bye or word level, but you can only overprogram a
> byte a fixed number of times before you need to erase it, *and* you can
> only change bits from 1 to 0 as James wrote.
>
> -- Paul.
>
> > -----Original Message-----
> > From: onestone [mailto:onestone@...]
> > Sent: 06 March 2003 01:04
> > To: msp430@yahoogroups.com
> > Subject: Re: [msp430] Writing to flash
> >
> >
> > Not according to SLAA130. This states that FLASH
> > reprogramming is possible at a byte level. ie erase/program
> > as a cycle.
> >
> > Al
> >
> > James Wagner wrote:
> > >
> > > Jardar -
> > >
> > > An important thing to remember: you can change flash bits
> > in only one
> > > direction. I believe that you can only change a  1 to a 0.
> > If you need
> > > to go the other way, your ONLY option is to clear the whole segment!
> > >
> > > Jim Wagner
> > >
> > > --- Jardar Johannes Maatje <maatje@...> wrote:
> > > > I an integer that I want to be located in flash memory on the
> > > > MSP430F1121 chip. But I have a problem making this work:
> > > >
> > > >
> > > >     #define ONBOARD_FLASH_ADDRESS 0x1080
> > > > ...
> > > >     uint *ptrToCounter  = (uint *) ONBOARD_FLASH_ADDRESS;
> > > >       *ptrToCounter =
> > > >
> > > >     FCTL2 = FWKEY + FSSEL0 + FN0;
> > > >     while ( FCTL3 & BUSY);
> > > >     FCTL3 = FWKEY;
> > > >     FCTL1 = FWKEY + WRT;
> > > >     *ptrToCounter = absoluteFlashPointer;
> > > >     FCTL1 = FWKEY;
> > > >     FCTL3 = FWKEY + LOCK;
> > > >     while ( ! (FCTL3 & WAIT) );
> > > >     absoluteFlashPointer = *ptrToCounter;
> > > >
> > > > When I read back the pointers are not the same.
> > > >
> > > > Jardar
> > > >
> > > >
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Yahoo! Tax Center - forms, calculators, tips, more
> > > http://taxes.yahoo.com/
> > >
> > >                    Yahoo! Groups Sponsor
> > >                        ADVERTISEMENT
> > >
> > >
> > >
> > > To unsubscribe from the msp430 group, send an email to:
> > > msp430-unsubscribe@egroups.com
> > >
> > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
> >
> > ------------------------ Yahoo! Groups Sponsor
> > ---------------------~--> Get 128 Bit SSL Encryption!
> > http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA> /CFFolB/TM
> >
> >
> > --------------------------------------------------------------
> > -------~->
> >
> > To unsubscribe from the msp430 group, send an email to:
> > msp430-unsubscribe@egroups.com
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
> > http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

So far I have just been using the flash toolkit for testing the device.
Now I'm designing print for the real application. What I was wondering
about is what the minimum number of pins that need to be connected to be
able to program the device. Do I realy need the JTAG pins just to be able
to program the device (ie a total of 6 pins as it says in slau048b).

Jardar

Hi All,

Does anyone know the size of segment in flash, on page 16 of SLAS272C is
states that it's size is 256bytes although on page 15 they say that it's
512 bytes
Segment B       01000-0107F  256 bytes
Segment A       01080-010FF  256 bytes
Segment n        01100-011FF  256 bytes
Segment n-1    01200-013FF  512 bytes
Segment n-2    01400-015FF  512 bytes
             Etc etc

Or
Segment B       01000-0107F  256 bytes
Segment A       01080-01100  256 bytes
Segment n        01200-013FF  512 bytes
Segment n-1    01400-015FF  512 bytes
Segment n-2    01600-017FF  512 bytes
             Etc etc


thanks
Martijn Broens



[Non-text portions of this message have been removed]

Both segments in Information memory (0x1000-0x107f, and 0x1080-
0x10ff) are 128 bytes long.
The segments in the rest of flash memory are 512 bytes long, except
for the area between 0x1100 and 0x11ff on F149 and F449 (and,
presumably, F169), which is one 256 byte long segment.

Michel

Free, full featured , 30 day trial version of AQ430 at
www.quadravox.com/aq430pa.htm

--- In msp430@yahoogroups.com, "Martijn Broens" <martijn@a...> wrote:
> Hi All,
>
> Does anyone know the size of segment in flash, on page 16 of
SLAS272C is
> states that it's size is 256bytes although on page 15 they say that
it's
> 512 bytes
> Segment B       01000-0107F  256 bytes
> Segment A       01080-010FF  256 bytes
> Segment n        01100-011FF  256 bytes
> Segment n-1    01200-013FF  512 bytes
> Segment n-2    01400-015FF  512 bytes
>             Etc etc
>
> Or
> Segment B       01000-0107F  256 bytes
> Segment A       01080-01100  256 bytes
> Segment n        01200-013FF  512 bytes
> Segment n-1    01400-015FF  512 bytes
> Segment n-2    01600-017FF  512 bytes
>             Etc etc
>
>
> thanks
> Martijn Broens
>
>
>
> [Non-text portions of this message have been removed]

The requirements are different if you use JTAG or serial bootloader.

JTAG is faster but you cannot reprogram after burning security fuses.
Bootload is slower but (I believe) is write-only. Bootload takes only 3
lines (plus ground?), I think, while JTAG takes more. The 6 JTAG lines
also includes ground so the penalty is 2 more lines than bootload.

Also, with care, you can share most of the JTAG lines with operational
I/O provided they are outputs from the micro and the external hardware
can tolerate the "strange" logic conditions during programming. I think
its much harder to do that with bootload lines.

Jim Wagner


--- Jardar Johannes Maatje <maatje@...> wrote:
> So far I have just been using the flash toolkit for testing the
> device.
> Now I'm designing print for the real application. What I was
> wondering
> about is what the minimum number of pins that need to be connected to
> be
> able to program the device. Do I realy need the JTAG pins just to be
> able
> to program the device (ie a total of 6 pins as it says in slau048b).
>
> Jardar
>


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Dear sir,

Thanks for clarifying the doubts.

i have one doubt about pull up/pull down resistor. I
want to exat limitations of minimum and maximum pull
up/dpown resistances and related calculation.

i came to know pull down resistane calculated fron
leakage current, but iam not confident on that.

So please clarify my doubt.

By
Venkat




--- Paul Curtis <plc@...> wrote:
> All,
>
> > What I can say, though, I've only stepped on one
> bug in the
> > IAR v2.09B beta compiler, which is fairly good
> going.  But
> > then, it is a beta, and perhaps it might even be
> cleared up
> > before they release.
>
> Oh, make that two bugs and a way to make the
> compiler snooze.  Tried to
> compile a 150 line program, left it going for over
> an hour, came back,
> 300MB of memory chewed by ICC430 and still no
> output, so killed the
> compiler.  Of course, it's only a beta, but I guess
> that these bugs
> won't be cleared up before release.  And as you
> know, IAR just love
> comparing Beta quality compilers in their
> advertising material and in
> side chats, so I thought I'd give them a dose of
> their own medicine. ;-)
>
> -- Paul.
>


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Hi

                              Can anyone really Help me in finding a display
which consumes minimum power cheapest and has a minimum pin requirement to
program with msp430f1232.

  bye

raghu



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more

[Non-text portions of this message have been removed]

The first thing you need to ask is "what kind of display"? Do you need
full graphics or is an alphanumeric character display OK?

If full graphics are needed, what pixel size?
If alphanumeric, how many lines and how many characters per line?

Do you care if it is LCD? LED? Fluorescent? Etc?

What physical size limits?

Jim Wagner

--- Raghavendra Bulusu <codemsp430@...> wrote:
>
> Hi
>
>                              Can anyone really Help me in finding a
> display which consumes minimum power cheapest and has a minimum pin
> requirement to program with msp430f1232.
>
>  bye
>
> raghu
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, and more
>
> [Non-text portions of this message have been removed]
>
>
>


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

On Thu, 6 Mar 2003 10:24:01 -0800 (PST), you wrote:

>The first thing you need to ask is "what kind of display"? Do you need
>full graphics or is an alphanumeric character display OK?
>
>If full graphics are needed, what pixel size?
>If alphanumeric, how many lines and how many characters per line?
>
>Do you care if it is LCD? LED? Fluorescent? Etc?
>
>What physical size limits?
>

I kinda like the looks of the Nixie tubes.

http://www.electricstuff.co.uk/nixclock.html

But somehow I doubt that will meet his needs.

Also remember that quite a number of the msp430 family members have
LCD drivers built right into them. I would expect (not having used
them for anything myself) that they would be low power and very
convenient to use.

Brian

-----------------------------------------------------
Brian C. Lane (W7BCL)                      Programmer
www.shinemicro.com   RF, DSP & Microcontroller Design

hi james
           I need a alpha numeric character display ,one line is enough atmost
two should be fine ,I prefer a lcd display and the physical size parameters are
.8" X1" with a tolerance of 15% . what difference ,LCD,LED ,fluorescent really
make.
Thanks
raghu

  James Wagner <ka7ehk@...> wrote:The first thing you need to ask is "what
kind of display"? Do you need
full graphics or is an alphanumeric character display OK?

If full graphics are needed, what pixel size?
If alphanumeric, how many lines and how many characters per line?

Do you care if it is LCD? LED? Fluorescent? Etc?

What physical size limits?

Jim Wagner

--- Raghavendra Bulusu <codemsp430@...> wrote:
>
> Hi
>
>                              Can anyone really Help me in finding a
> display which consumes minimum power cheapest and has a minimum pin
> requirement to program with msp430f1232.
>
>  bye
>
> raghu
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, and more
>
> [Non-text portions of this message have been removed]
>
>
>


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Yahoo! Groups Sponsor

To unsubscribe from the msp430 group, send an email to:
msp430-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more

[Non-text portions of this message have been removed]

Hello Raghu -

There are many manufacturers that make 2 line, 16, 20, or 24 characters
per line (I think those are correct numbers) LCD. The common interface
is set up for parallel, either 4 or 8 data bits (width). In this
interface type, there is a read/write line, a strobe (I think), and a
line that tells the display whether the data is a register address or
actual display data. The displays, themselves do not take very much
power but backlight does. Look at Stanley for examples (also Seiko,
Citizen, Lumex). This kind of display has the LCD mounted in a metal
frame on a circuit board. The display drivers are on the back of the
board and the parallel interface is at one end. They are about 4cm X
22cm (last number depends on number of characters) and about 1cm thick.
Cost depends on number of characters and the kind of backlight. Also,
displays of this kind are readily available through many distributors;
in the U.S., try DigiKey.

Jim Wagner

--- Raghavendra Bulusu <codemsp430@...> wrote:
>
> hi james
>           I need a alpha numeric character display ,one line is
> enough atmost two should be fine ,I prefer a lcd display and the
> physical size parameters are .8" X1" with a tolerance of 15% . what
> difference ,LCD,LED ,fluorescent really make.
> Thanks
> raghu
>
>  James Wagner <ka7ehk@...> wrote:The first thing you need to
> ask is "what kind of display"? Do you need
> full graphics or is an alphanumeric character display OK?
>
> If full graphics are needed, what pixel size?
> If alphanumeric, how many lines and how many characters per line?
>
> Do you care if it is LCD? LED? Fluorescent? Etc?
>
> What physical size limits?
>
> Jim Wagner
>
> --- Raghavendra Bulusu <codemsp430@...> wrote:
> >
> > Hi
> >
> >                              Can anyone really Help me in finding a
> > display which consumes minimum power cheapest and has a minimum pin
> > requirement to program with msp430f1232.
> >
> >  bye
> >
> > raghu
> >
> >
> >
> > ---------------------------------
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, and more
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
>
> Yahoo! Groups Sponsor
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, and more
>
> [Non-text portions of this message have been removed]
>
>


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Well, he did specify the '1232, but you're right: passive LCDs fit the
other requirements mentioned (cheap, low power).  If an alternative micro
is in the cards Softbaugh makes a cool little experimenter's board with LCD
for the low-cost '412.  They also sell the LCDs separately.

www.softbaugh.com

Luminex also makes tiny, very low cost (35 cents or so in qty)
off-the-shelf LCD panels:

http://www.lumex.com/


--Bruce



> Also remember that quite a number of the msp430 family members have
> LCD drivers built right into them. I would expect (not having used
> them for anything myself) that they would be low power and very
> convenient to use.
>
> Brian