Hi,

Yes, I change this regeister and interrupts are enabled. But note that the
processor doest even serve the ISR.

However, NMI isnt affecteded by the GIE interrupt flag.

Both NMIE and NMIES are setup.

Also, the NMI is working as long as the processor is in Active mode, so it
seems it has something to do with the low power modes.


Johan Schuld
Adesys B.V.
Postbus 60
2290 NR  Wateringen

Molenweer 4
2291 NR  Wateringen

The Netherlands
tel: 0174-296389
fax: 0174-293807
www.adesys.nl

> -----Oorspronkelijk bericht-----
> Van: michelqv [mailto:michel@mich...]
> Verzonden: maandag 8 september 2003 16:08
> Aan: msp430@msp4...
> Onderwerp: [msp430] Re: NMI when in LPM3
>
>
> No, I meant the LPM3 bits in the saved copy (on the stack) of the
> status register. Also, I assume that you do have interrupts enabled
> when you go into LPM3?
>
> Michel
>
> --- In msp430@msp4..., "Johan Schuld" <johan@a...> wrote:
> > Hi,
> >
> > You mean the NMIIFG bit in IFG1? This is cleared inside the ISR.
> But the ISR
> > doest execute at all when in LPM3. When in Active mode the ISR
> functions as
> > it should.
> >
> > I test this by setting a (HW) breakpoint inside the ISR of the NMI
> > interrupt. The breakpoint isnt reached when in LPM3. As soon as I
> leave LPM3
> > to active mode, the breakpiont is reached.
> >
> > Also, when in active mode, and the interrupt falls, the breakpoint
> is
> > reached immideately.
> >
> > Thanks for your help,
> >
> > Johan Schuld
> > Adesys B.V.
> > Postbus 60
> > 2290 NR  Wateringen
> >
> > Molenweer 4
> > 2291 NR  Wateringen
> >
> > The Netherlands
> > tel: 0174-296389
> > fax: 0174-293807
> > www.adesys.nl
> >
> > > -----Oorspronkelijk bericht-----
> > > Van: michelqv [mailto:michel@q...]
> > > Verzonden: vrijdag 5 september 2003 19:33
> > > Aan: msp430@msp4...
> > > Onderwerp: [msp430] Re: NMI when in LPM3
> > >
> > >
> > > Do you modify the stored status register value when executing the
> ISR?
> > >
> > > Michel
> > >
> > > --- In msp430@msp4..., "Johan Schuld"
<johan@a...> wrote:
> > > > Hello,
> > > >
> > > > I'm using a MSP430F135 in LPM3. I am using the RST/NMI
pin as
> NMI.
> > > The
> > > > interrupt handling works as it should when in wakeup mode.
> > > >
> > > > As soon as I enter LMP3, and I generate the interrupt the
> processor
> > > does not
> > > > handle it. When I wakeup the processor by some other reason,
> the NMI
> > > > interrupt flag is set, and the processor handles it at that
> time.
> > > (the NMI
> > > > interrupt situation does not exist anymore on at that time).
> > > >
> > > > So it seems that the NMI interrupt flag is set when in LPM3,
> but not
> > > > handled.
> > > >
> > > > The manuals say that when in LPM3 any device that is able to
> > > generate an
> > > > inerrupt (external interrupts and blocks running on ACLK),
and
> is
> > > serviced.
> > > >
> > > > I use Timer-A and 2 external interrupt (I/O) pins, and they
> work as
> > > it
> > > > should in LMP3
> > > >
> > > > Is NMI an exception ?
> > > >
> > > > Oh. I use the Quadravox compiler.
> > > >
> > > > Thanks for your help,
> > > >
> > > > Johan Schuld
> > > > Adesys B.V.
> > > > Postbus 60
> > > > 2290 NR  Wateringen
> > > >
> > > > Molenweer 4
> > > > 2291 NR  Wateringen
> > > >
> > > > The Netherlands
> > > > tel: 0174-296389
> > > > fax: 0174-293807
> > > > www.adesys.nl
> > >
> > >
> > >
> > > .
> > >
> > >
> > >
> > > ">http://docs.yahoo.com/info/terms/
> > >
> > >
> > >
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>
>

No, I meant the LPM3 bits in the saved copy (on the stack) of the 
status register. Also, I assume that you do have interrupts enabled 
when you go into LPM3?

Michel

--- In msp430@msp4..., "Johan Schuld" <johan@a...> wrote:
> Hi,
> 
> You mean the NMIIFG bit in IFG1? This is cleared inside the ISR. 
But the ISR
> doest execute at all when in LPM3. When in Active
mode the ISR 
functions as
> it should.
> 
> I test this by setting a (HW) breakpoint inside the ISR of the NMI
> interrupt. The breakpoint isnt reached when in LPM3. As soon as I 
leave LPM3
> to active mode, the breakpiont is reached.
> 
> Also, when in active mode, and the interrupt falls, the breakpoint 
is
> reached immideately.
> 
> Thanks for your help,
> 
> Johan Schuld
> Adesys B.V.
> Postbus 60
> 2290 NR  Wateringen
> 
> Molenweer 4
> 2291 NR  Wateringen
> 
> The Netherlands
> tel: 0174-296389
> fax: 0174-293807
> www.adesys.nl
> 
> > -----Oorspronkelijk bericht-----
> > Van: michelqv [mailto:michel@q...]
> > Verzonden: vrijdag 5 september 2003 19:33
> > Aan: msp430@msp4...
> > Onderwerp: [msp430] Re: NMI when in LPM3
> >
> >
> > Do you modify the stored status register value when executing the 
ISR?
> >
> > Michel
> >
> > --- In msp430@msp4..., "Johan Schuld" <johan@a...>
wrote:
> > > Hello,
> > >
> > > I'm using a MSP430F135 in LPM3. I am using the RST/NMI pin
as 
NMI.
> > The
> > > interrupt handling works as it should when in wakeup mode.
> > >
> > > As soon as I enter LMP3, and I generate the interrupt the 
processor
> > does not
> > > handle it. When I wakeup the processor by some other reason, 
the NMI
> > > interrupt flag is set, and the processor
handles it at that 
time.
> > (the NMI
> > > interrupt situation does not exist anymore on at that time).
> > >
> > > So it seems that the NMI interrupt flag is set when in LPM3, 
but not
> > > handled.
> > >
> > > The manuals say that when in LPM3 any device that is able to
> > generate an
> > > inerrupt (external interrupts and blocks running on ACLK), and 
is
> > serviced.
> > >
> > > I use Timer-A and 2 external interrupt (I/O) pins, and they 
work as
> > it
> > > should in LMP3
> > >
> > > Is NMI an exception ?
> > >
> > > Oh. I use the Quadravox compiler.
> > >
> > > Thanks for your help,
> > >
> > > Johan Schuld
> > > Adesys B.V.
> > > Postbus 60
> > > 2290 NR  Wateringen
> > >
> > > Molenweer 4
> > > 2291 NR  Wateringen
> > >
> > > The Netherlands
> > > tel: 0174-296389
> > > fax: 0174-293807
> > > www.adesys.nl
> >
> >
> >
> > .
> >
> >
> >
> > ">http://docs.yahoo.com/info/terms/
> >
> >
> >

Hi,

You mean the NMIIFG bit in IFG1? This is cleared inside the ISR. But the ISR
doest execute at all when in LPM3. When in Active mode the ISR functions as
it should.

I test this by setting a (HW) breakpoint inside the ISR of the NMI
interrupt. The breakpoint isnt reached when in LPM3. As soon as I leave LPM3
to active mode, the breakpiont is reached.

Also, when in active mode, and the interrupt falls, the breakpoint is
reached immideately.

Thanks for your help,

Johan Schuld
Adesys B.V.
Postbus 60
2290 NR  Wateringen

Molenweer 4
2291 NR  Wateringen

The Netherlands
tel: 0174-296389
fax: 0174-293807
www.adesys.nl

> -----Oorspronkelijk bericht-----
> Van: michelqv [mailto:michel@mich...]
> Verzonden: vrijdag 5 september 2003 19:33
> Aan: msp430@msp4...
> Onderwerp: [msp430] Re: NMI when in LPM3
>
>
> Do you modify the stored status register value when executing the ISR?
>
> Michel
>
> --- In msp430@msp4..., "Johan Schuld" <johan@a...> wrote:
> > Hello,
> >
> > I'm using a MSP430F135 in LPM3. I am using the RST/NMI pin as
NMI.
> The
> > interrupt handling works as it should when in wakeup mode.
> >
> > As soon as I enter LMP3, and I generate the interrupt the processor
> does not
> > handle it. When I wakeup the processor by some other reason, the NMI
> > interrupt flag is set, and the processor handles it at that time.
> (the NMI
> > interrupt situation does not exist anymore on at that time).
> >
> > So it seems that the NMI interrupt flag is set when in LPM3, but not
> > handled.
> >
> > The manuals say that when in LPM3 any device that is able to
> generate an
> > inerrupt (external interrupts and blocks running on ACLK), and is
> serviced.
> >
> > I use Timer-A and 2 external interrupt (I/O) pins, and they work as
> it
> > should in LMP3
> >
> > Is NMI an exception ?
> >
> > Oh. I use the Quadravox compiler.
> >
> > Thanks for your help,
> >
> > Johan Schuld
> > Adesys B.V.
> > Postbus 60
> > 2290 NR  Wateringen
> >
> > Molenweer 4
> > 2291 NR  Wateringen
> >
> > The Netherlands
> > tel: 0174-296389
> > fax: 0174-293807
> > www.adesys.nl
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>
>

Bruce Cannon wrote:
> Not in any way meaning to be argumentative here,
I'm just interested in
> this subject:
> 
> 
>>Only comment lines that are not obvious. What's the point of
>>"load 7 to R4"?
> 
> 
> Well, these possible answers occur to me immediately:
> 
> 1. 'Obvious' to who?  Something which is obvious to me when
I'm doing it
> often isn't a year later, and also what is obvious to me might not be
to
> someone inspecting, reviewing, revising or maintaining my code.

The most common things programmers do is either fail to comment, or over 
comment, making it difficult to pick meaningful comments from the noise. 
My example illustrates this. If the person reading the code above has 
even the slightest knowledge of almost any assembler they would know:-

	MOV	#7,R4		;load 7 to R4

That the instruction itself is comment enough. There is no point 
describing an instruction. However if the line read:-

	MOV	#7,R4		;load days in a week to R4

The comment now has some meaning, but, even this is over commenting, 
since a better solution would be:-

	MOV	#WeekDays,R4

Now by applying another 'good' practice, that of using meaningful 
labels/names, the line doesn't need commenting because the intent is 
obvious from the instruction.


> 2. The imaginary example you gave isn't
technically a comment; by my own
> definition it's filler placed by a lazy programmer who is fulfilling
the
> letter of their standards requirement but has no actual interest in doing a
> good job of communicating to others.  I think a real comment would explain
> both how and why, and in context.

See my expansion of this above. What you call filler, and I call noise, 
is what many people call comments. The single bit codec example I gave 
is over commented in the header file, but, I believe only contains 
meaningful comment in the code. The over commenting in the header is 
there to explain some of the pitfalls people might meet implementing 
this code.

> 3. Comments that really do explain what the
program is intended to do, blow
> by blow and line for line, can initially aid inspection (via looking for
> the difference between what the programmer thought he was doing and what he
> really did).

I think that line by line commentaRY is rarely needed. I like to 
describe a sub-routines intention in a small header, which also serves 
to separate sub-routines and, I believe, improve over all clarity. I 
just took a quick look at the Shell code I sent you. An intersting 
experience. The MAIN module has what I consider to be a reasonable level 
of commentary, as does the INIT module. The ISR module is a bit sparse, 
but mainly because I heavily hacked out most of the meaningful stuff 
from it. The LCD2 module on the other hand is almost void of commentary. 
This is an ancient piece of code, it started as 8051 code about 12 years 
ago, was translated to HC05, then HC11, then PIC, and finally into 
MSP430. Through those levels of translation it became so familiar to me 
that, being a bit lazy, I gradually shed the comments.

This, of course is a common problem with more experienced programmers. 
My only excuse is that I don't write code that other people will 
maintain, and I will understand it 10 years later if I pick it up. But 
then that's what we all say!

> 4. Later, after that's sync'd, they can
help another programmer understand
> the program's form and function much more quickly and easily.

Well, I no longer teach, nor do I subscribe to thia argument 
particularly. On the odd occasion when I do post code snippets here I 
think I comment them fairly fully, but, like everyone here I'm biased by 
my experience or lack of it.

> 
> Though I can also see the flipside of those arguments, where there is
> inevitably a difference between the two languages.  Also, as always with
> me, these are based on fairly limited experience, so I welcome
> clarification as needed.

Cheers

Al

Hi Mike,

Thanks!!! 

Rgds...
Nav

-----Original Message-----
From: Mike [mailto:mike@mike...] 
Sent: Sunday, September 07, 2003 3:06 AM
To: msp430@msp4...
Subject: [msp430] Re: SPI slave code example

Hi Nav,
Take a look at my RTC example in the files section. It's a 2-wire 
interface, similar to either I2C or SPI. All you'd need to do is 
separate incoming and outgoing data. There's also a master side as 
well, so you can test it.
Also, TI has several examples of SPI on their website.
Mike.

> Please let me know you have SPI slave example
using
> the MSP430 as a SPI slave. 




.

 

">http://docs.yahoo.com/info/terms/ 

Not in any way meaning to be argumentative here, I'm just interested
in
this subject:

> Only comment lines that are not obvious.
What's the point of
> "load 7 to R4"?

Well, these possible answers occur to me immediately:

1. 'Obvious' to who?  Something which is obvious to me when I'm
doing it
often isn't a year later, and also what is obvious to me might not be to
someone inspecting, reviewing, revising or maintaining my code.
2. The imaginary example you gave isn't technically a comment; by my own
definition it's filler placed by a lazy programmer who is fulfilling the
letter of their standards requirement but has no actual interest in doing a
good job of communicating to others.  I think a real comment would explain
both how and why, and in context.
3. Comments that really do explain what the program is intended to do, blow
by blow and line for line, can initially aid inspection (via looking for
the difference between what the programmer thought he was doing and what he
really did).
4. Later, after that's sync'd, they can help another programmer
understand
the program's form and function much more quickly and easily.

Though I can also see the flipside of those arguments, where there is
inevitably a difference between the two languages.  Also, as always with
me, these are based on fairly limited experience, so I welcome
clarification as needed.

--Bruce

Bruce Cannon wrote:

>>Hey, c'mon I never said I don't
debug. The debug and test phase is
>>usually much longer than the software design and code phase, not
>>necessarily because it is buggy, but because I want to make sure it
>>isn't, and that there are no subtleties that might trip things up.
It is
>>the easiest thing in the world to do.
> 
> 
> I found the "I don't need to debug much" comment funny
because personally,
> with my level of experience, easily 1/2 my time is spent debugging.
> Actually, probably more like 3/4 or higher when I consider testing.
> Anyway, no offense!  I fully accept the (for me) abstract concept that
> highly skilled programmers don't debug much.  I'll even try and
remember,
> after a frustrating 20hr session trying to get something to work, that for
> them it's the easiest thing in the world to do  ;)
> 
> 
>>Omitting to use CMP.b instead of
>>CMP, for example will compile perfectly, and may pass most simple
>>functional testing, then a month after shipping might crash the system
>>in a big way. However I don't want strong typing, because the
ability to
>>use byte and word almost interchangably is very powerful. What I would
>>like is an assembler that warns of this. My typing is so poor for
>>various reasons that most of my bugs are typos of this order. I should
>>write my own filter, but have been too lazy.
> 
> 
> Would the assembler warn of all combined word-->byte
> assignments/operations, or try and figure out which might be risky?  The
> former would be annoying but useful (and likely switch-offable).  The
> latter sounds hard.

If I were to sit and write a filter I would write it for my style of 
assembler ccoding. I prefer to use the format DS n to assign n bytes to 
a label, this makes things as relocatable as you want. Thus if I use DS 
1 and later use a word access I would expect a warning, similarly if I 
used DS 2 then later used a byte access. This would be a comparatively 
simple filter to implement I would think, and a major boon to debugging. 
It is even easier usign DB and DW, but much harder using the Ti format 
of .set, or the more conventional EQU. I tend to avoid the latter as it 
fixes an address. Any thing DS > 2 is ignored since it is a table.


> 
> Though I notice from looking at code examples that most programmers
don't
> do this: I don't write any instruction without explicitly specifying
the
> length.  I think this helps me inspect for errors of the type you're
> mentioning.  But I'm also of the "comment every line" school
of thought,
> which I also know many coders think is absurd.

Although it makes a lot of sense to explicitly use .b and .w these are 
not a convention that most prgrammers have grown up with, I imagine. The 
majority of us in embedded systems grew up on 8 bit architectures, no 16 
bit specials, and most other 16 bit and upwards devices I've used have 
different conventions for 8/16/32 bit encoding. Hence most of us 
inherently type		CMP	R4,R5.

In my particular case I'm a bit lazy, at least 25% of all words I type 
have typos, and it gets more than frstrating having to constantly edit 
to make things legible. you might notice that I sometimes turn down the 
editor, and more jumble than normal appears. B & W aer left handed keys, 
  most of my typing problems are related to slow responses in my left 
arm, ie that side of the keyboard gets mangled most.

Only comment lines that are not obvious. What's the point of "load 7
to R4"?

Cheers

Al

Hi Nav,
Take a look at my RTC example in the files section. It's a 2-wire 
interface, similar to either I2C or SPI. All you'd need to do is 
separate incoming and outgoing data. There's also a master side as 
well, so you can test it.
Also, TI has several examples of SPI on their website.
Mike.

> Please let me know you have SPI slave example
using
> the MSP430 as a SPI slave. 

> Hey, c'mon I never said I don't debug. The debug and test
phase is
> usually much longer than the software design and
code phase, not
> necessarily because it is buggy, but because I want to make sure it
> isn't, and that there are no subtleties that might trip things up. It
is
> the easiest thing in the world to do.

I found the "I don't need to debug much" comment funny because
personally,
with my level of experience, easily 1/2 my time is spent debugging.
Actually, probably more like 3/4 or higher when I consider testing.
Anyway, no offense!  I fully accept the (for me) abstract concept that
highly skilled programmers don't debug much.  I'll even try and
remember,
after a frustrating 20hr session trying to get something to work, that for
them it's the easiest thing in the world to do  ;)

> Omitting to use CMP.b instead of
> CMP, for example will compile perfectly, and may pass most simple
> functional testing, then a month after shipping might crash the system
> in a big way. However I don't want strong typing, because the ability
to
> use byte and word almost interchangably is very powerful. What I would
> like is an assembler that warns of this. My typing is so poor for
> various reasons that most of my bugs are typos of this order. I should
> write my own filter, but have been too lazy.

Would the assembler warn of all combined word-->byte
assignments/operations, or try and figure out which might be risky?  The
former would be annoying but useful (and likely switch-offable).  The
latter sounds hard.

Though I notice from looking at code examples that most programmers don't
do this: I don't write any instruction without explicitly specifying the
length.  I think this helps me inspect for errors of the type you're
mentioning.  But I'm also of the "comment every line" school of
thought,
which I also know many coders think is absurd.

>As to the simulator the
> reason I don't use them much is that they don't really simulate
hardware
>   in a useful fashion. I do use them to test out new algorithms,
> especially ones whose function might be obscure, but I wouldn't miss
> one. Having said that years ago when I first started out I would have
> given anything for a decent simulator.

I can definitely see that the more proficient I get with a particular
architecture and instruction set, the less I'd use a simulator.

--Bruce

Dear All,

Please let me know you have SPI slave example using
the MSP430 as a SPI slave. 
Please send me as soon as possible.

Thanks...
Nav

__________________________________