Hi,
I am trying to run a function which uses serial port communication, so serial interrupts, in the timer interrupt service routine. Although the same function works correctly in the main function, it does not do so in the timer isr. I tried to set global interrupt bit(GIE) whether that bit may be reset or not but; after that, the device resets itself. That seemed to not to be solution. What may the sloution be?
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

You do not understand how interruption works. And seems not understand how =
serial interface works.
The MCU reseting after enabling int (GIE=3D1) inside an interrupt servicing=
means, probably, that your
software is loosing the control that result in stack error.
Enabling the global interrupt inside an interrupt servicing is a common act=
ion to allow the system
do not loose interrupt events. But, to do this correctly you must understan=
d how interruption works
in this microcontroller.
Read the device user=C2=B4s guide and other books about this subject. You m=
ust understand this correctly
before trying to solve this problem. If you solve this by chance or with so=
me direct help you will
never understand the topic and will fall in the same or worst situations in=
the future.
One hint: any interrupt service routine must be as short and fast as possib=
le. Do not make loops there.

-Augusto

On Qui 27/08/09 06:52 , e...@yahoo.com sent:
> Hi,
> I am trying to run a function which uses serial port communication,
> so serial interrupts, in the timer interrupt service routine.
> Although the same function works correctly in the main function, it
> does not do so in the timer isr. I tried to set global interrupt
> bit(GIE) whether that bit may be reset or not but; after that, the
> device resets itself. That seemed to not to be solution. What may the
> sloution be?
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>=20

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I agree. Nested interrupts should be avoided. I've never had the need to do=
that;I've always found a way around it and it totally depends on the appli=
cation. You might need to change your program strategy.

As Augusto hinted, the way to do it is keeping the ISRs as short and fast a=
s possible. Anything that doesn't need to be done inside the ISR should be =
signaled to the main loop. For example don't print/send variables from with=
in the ISR, instead save the value to a global variable or buffer and let t=
he main loop print it.

But why do you need to enable serial interrupts within the Timer ISR? can't=
you poll the serial flag? Can't you lower the baud rate? doesn't the other=
device have hardware control flow (you can signal the other device not to =
send data while you're in the Timer ISR)?

Regards,
Michael K.

--- In m...@yahoogroups.com, Augusto Einsfeldt wrote:
>
> You do not understand how interruption works. And seems not understand ho=
w serial interface works.
> The MCU reseting after enabling int (GIE=3D1) inside an interrupt servici=
ng means, probably, that your
> software is loosing the control that result in stack error.
> Enabling the global interrupt inside an interrupt servicing is a common a=
ction to allow the system
> do not loose interrupt events. But, to do this correctly you must underst=
and how interruption works
> in this microcontroller.
> Read the device user=C2=B4s guide and other books about this subject. You=
must understand this correctly
> before trying to solve this problem. If you solve this by chance or with =
some direct help you will
> never understand the topic and will fall in the same or worst situations =
in the future.
> One hint: any interrupt service routine must be as short and fast as poss=
ible. Do not make loops there.
>=20
> -Augusto
>=20
>=20
>=20
> On Qui 27/08/09 06:52 , erdemdilmen@... sent:
> > Hi,
> > I am trying to run a function which uses serial port communication,
> > so serial interrupts, in the timer interrupt service routine.
> > Although the same function works correctly in the main function, it
> > does not do so in the timer isr. I tried to set global interrupt
> > bit(GIE) whether that bit may be reset or not but; after that, the
> > device resets itself. That seemed to not to be solution. What may the
> > sloution be?
> >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,
>I am trying to run a function which uses serial port communication, so serial interrupts, in the timer interrupt service routine. Although the same function works correctly in the main function, it does not do so in the timer isr. I tried to set global interrupt bit(GIE) whether that bit may be reset or not but; after that, the device resets itself. That seemed to not to be solution. What may the sloution be?
>------------------------------------
>
>Hi,
I read the manual of msp430f248 and i know correctly how interrupts work. If i didnt understand it how can i use serial interrupts or timer interrupts which work correctly? Here the non-understood thing is my question. I can already use serial interrupts, e.g. making serial comminucation and printing something on console. In the main code, all initializations are amde for UART and timer modules and also their interrupts are enabled so that; the PC can access the isr of timer module and i can print something while PC is still in the main code. But why can not it print something while it is the isr of timer? I read the manuals and i didnt see anything related to that. Such a problem is an undefined one so; there is not a solution defined that can encounter it. Serial communication does not work in the isr, so that means serial interrupts do not work. I read in the manual that msp430 let interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(comes nonsense to me) while accessing to the isr of timer so; serial interrupts are disabled. Then i tried such a solution that sets the GIE bit in the isr in timer but; that was not a solution as it seems because it resets the device. If a solution to that can not be found; i will do nothing but change my program strategy.
In fact; i do not preffer making long work like serial communication in the timer isr but the reason for that is as follows. I want msp430 to make serial communication with a slave device and print the data received from it at each 5 seconds. I will do that by timer interrupt. But in that 5 seconds, i want it to be LPM_3 and wake up only for serial communication. I thought maybe it can sleep 5 seconds and in the isr it can make its serial communication. It has nothing else to do in the main code or in other some isr so i thought it wont be a problem to make a long work in the isr of timer. But it seems that strategy doesnt work and i will change it.
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,
I read the manual of msp430f248 and i know correctly how interrupts work. I=
f i didnt understand it how can i use serial interrupts or timer interrupts=
which work correctly? Here the non-understood thing is my question. I can =
already use serial interrupts, e.g. making serial comminucation and printin=
g something on console. In the main code, all initializations are amde for =
UART and timer modules and also their interrupts are enabled so that; the P=
C can access the isr of timer module and i can print something while PC is =
still in the main code. But why can not it print something while it is the =
isr of timer? I read the manuals and i didnt see anything related to that. =
Such a problem is an undefined one so; there is not a solution defined that=
can encounter it. Serial communication does not work in the isr, so that m=
eans serial interrupts do not work. I read in the manual that msp430 let in=
terrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(co=
mes nonsense to me) while accessing to the isr of timer so; serial interrup=
ts are disabled. Then i tried such a solution that sets the GIE bit in the =
isr in timer but; that was not a solution as it seems because it resets the=
device. If a solution to that can not be found; i will do nothing but chan=
ge my program strategy.
In fact; i do not preffer making long work like serial communication in the=
timer isr but the reason for that is as follows. I want msp430 to make ser=
ial communication with a slave device and print the data received from it a=
t each 5 seconds. I will do that by timer interrupt. But in that 5 seconds,=
i want it to be LPM_3 and wake up only for serial communication. I thought=
maybe it can sleep 5 seconds and in the isr it can make its serial communi=
cation. It has nothing else to do in the main code or in other some isr so =
i thought it wont be a problem to make a long work in the isr of timer. But=
it seems that strategy doesnt work and i will change it.=20

--- In m...@yahoogroups.com, "tintronic" wrote:
>
> I agree. Nested interrupts should be avoided. I've never had the need to =
do that;I've always found a way around it and it totally depends on the app=
lication. You might need to change your program strategy.
>=20
> As Augusto hinted, the way to do it is keeping the ISRs as short and fast=
as possible. Anything that doesn't need to be done inside the ISR should b=
e signaled to the main loop. For example don't print/send variables from wi=
thin the ISR, instead save the value to a global variable or buffer and let=
the main loop print it.
>=20
> But why do you need to enable serial interrupts within the Timer ISR? can=
't you poll the serial flag? Can't you lower the baud rate? doesn't the oth=
er device have hardware control flow (you can signal the other device not t=
o send data while you're in the Timer ISR)?
>=20
> Regards,
> Michael K.
>=20
> --- In m...@yahoogroups.com, Augusto Einsfeldt wrote:
> >
> > You do not understand how interruption works. And seems not understand =
how serial interface works.
> > The MCU reseting after enabling int (GIE=3D1) inside an interrupt servi=
cing means, probably, that your
> > software is loosing the control that result in stack error.
> > Enabling the global interrupt inside an interrupt servicing is a common=
action to allow the system
> > do not loose interrupt events. But, to do this correctly you must under=
stand how interruption works
> > in this microcontroller.
> > Read the device user=C2=B4s guide and other books about this subject. Y=
ou must understand this correctly
> > before trying to solve this problem. If you solve this by chance or wit=
h some direct help you will
> > never understand the topic and will fall in the same or worst situation=
s in the future.
> > One hint: any interrupt service routine must be as short and fast as po=
ssible. Do not make loops there.
> >=20
> > -Augusto
> >=20
> >=20
> >=20
> > On Qui 27/08/09 06:52 , erdemdilmen@ sent:
> > > Hi,
> > > I am trying to run a function which uses serial port communication,
> > > so serial interrupts, in the timer interrupt service routine.
> > > Although the same function works correctly in the main function, it
> > > does not do so in the timer isr. I tried to set global interrupt
> > > bit(GIE) whether that bit may be reset or not but; after that, the
> > > device resets itself. That seemed to not to be solution. What may the
> > > sloution be?
> > >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

You only think you understand it, but from your response it is
absolutely clear that you have only a vague idea of what is really
happening. The other posters were correct. You should never service an
interrupt from within another interrupt handler unless it is absolutely
unavoidable, and in my 40 years in this industry I can count the number
of times I have found tis to be the case on one hand. You have to
analyse you problem more thoroughly. The purpose of an interrupt is to
recognise that a fast moving event has occurred, so that it doesn't get
lost. To record that event, and perhpas to preserve some data regarding
that event. In the case of a pulse it might be the time at which that
event occurred, be that system time, or real time, or some other time,
or, as in the case of serial communications it might be the received
data itself, or the fact that a byte of data has successfully been
transmitted and the UART is ready for the next byte. NONE of these
things have to be physically executed from the interrupt handler, they
can all be handled from your main routine, the purpose of the interrupt
handler is to trap the event using as little time as possible, so that
other real world events are never missed. If you are sat in one nested
interrupt after another servicing endless depths of nesting you will
miss what is happening in the real world until your program eventually
surfaces for breath.

here is a simple pseudo code description of one way to handle interrupts:-

ORG RAMSTART

TASKQ DS 16 ;RESERVE SPACE FOR 16 TASKS

ISR1:
clear the calling flag if not auto cleared
push service task1 onto task queue
double increment task pointer
goto task exit

Isr2:
push service task onto task queue
double increment task pointer
task_exit:
set saved STATUS_REG on STACK to LPM0
RETI

MAINCODE:
SET LPM3
TEST_TASK:
TST TASKPTR
JZ MAINCODE
CALL @TASKQ
CALL TASKDEQ ;REMOVE LAST TASK FROM Q
(figure this out for yourself)
JMP TEST_TASK

This code only wakes up after an event has pushed a task onto the queue.
The oldest task is serviced, but as soon as the device wakes up any
queued interrupts are also serviced, and get the opportunity to push
their own tasks onto the queue. So you get the opportunity to manage
this. First of all you can test if the ISR was called while in sleep
mode, and exit accordingly, then you can adjust stratgey of how you
place the task into the queue based on this. but the key thing is that
this takes place in the foreground, not in the ISR.

Obviously this is a simple illustration and not a fully functional,
robust design. When designing a system that handles real world events it
is the job of the designer to first of all determine the highest rate
that each ISR will be called at, and, for time constrained inputs, to
determine how long the ISR event is present for, then to design their
ISR handlers in such a way that guarantees that in the worst possible
case, where all interrupts occur sequentially, or at their highest
repetition rates, that none of the events will be missed. Remember that
events are latched by the interrupt handler. The absolute worst strategy
to adopt is usually that of nesting isr handlers.

Cheers

Al

jedi_erdi wrote:
> Hi,
> I read the manual of msp430f248 and i know correctly how interrupts work. If i didnt understand it how can i use serial interrupts or timer interrupts which work correctly? Here the non-understood thing is my question. I can already use serial interrupts, e.g. making serial comminucation and printing something on console. In the main code, all initializations are amde for UART and timer modules and also their interrupts are enabled so that; the PC can access the isr of timer module and i can print something while PC is still in the main code. But why can not it print something while it is the isr of timer? I read the manuals and i didnt see anything related to that. Such a problem is an undefined one so; there is not a solution defined that can encounter it. Serial communication does not work in the isr, so that means serial interrupts do not work. I read in the manual that msp430 let interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(comes nonsense
to me) while accessing to the isr of timer so; serial interrupts are disabled. Then i tried such a solution that sets the GIE bit in the isr in timer but; that was not a solution as it seems because it resets the device. If a solution to that can not be found; i will do nothing but change my program strategy.
> In fact; i do not preffer making long work like serial communication in the timer isr but the reason for that is as follows. I want msp430 to make serial communication with a slave device and print the data received from it at each 5 seconds. I will do that by timer interrupt. But in that 5 seconds, i want it to be LPM_3 and wake up only for serial communication. I thought maybe it can sleep 5 seconds and in the isr it can make its serial communication. It has nothing else to do in the main code or in other some isr so i thought it wont be a problem to make a long work in the isr of timer. But it seems that strategy doesnt work and i will change it.
>
> --- In m...@yahoogroups.com, "tintronic" wrote:
>> I agree. Nested interrupts should be avoided. I've never had the need to do that;I've always found a way around it and it totally depends on the application. You might need to change your program strategy.
>>
>> As Augusto hinted, the way to do it is keeping the ISRs as short and fast as possible. Anything that doesn't need to be done inside the ISR should be signaled to the main loop. For example don't print/send variables from within the ISR, instead save the value to a global variable or buffer and let the main loop print it.
>>
>> But why do you need to enable serial interrupts within the Timer ISR? can't you poll the serial flag? Can't you lower the baud rate? doesn't the other device have hardware control flow (you can signal the other device not to send data while you're in the Timer ISR)?
>>
>> Regards,
>> Michael K.
>>
>> --- In m...@yahoogroups.com, Augusto Einsfeldt wrote:
>>> You do not understand how interruption works. And seems not understand how serial interface works.
>>> The MCU reseting after enabling int (GIE=1) inside an interrupt servicing means, probably, that your
>>> software is loosing the control that result in stack error.
>>> Enabling the global interrupt inside an interrupt servicing is a common action to allow the system
>>> do not loose interrupt events. But, to do this correctly you must understand how interruption works
>>> in this microcontroller.
>>> Read the device user´s guide and other books about this subject. You must understand this correctly
>>> before trying to solve this problem. If you solve this by chance or with some direct help you will
>>> never understand the topic and will fall in the same or worst situations in the future.
>>> One hint: any interrupt service routine must be as short and fast as possible. Do not make loops there.
>>>
>>> -Augusto
>>>
>>>
>>>
>>> On Qui 27/08/09 06:52 , erdemdilmen@ sent:
>>>> Hi,
>>>> I am trying to run a function which uses serial port communication,
>>>> so serial interrupts, in the timer interrupt service routine.
>>>> Although the same function works correctly in the main function, it
>>>> does not do so in the timer isr. I tried to set global interrupt
>>>> bit(GIE) whether that bit may be reset or not but; after that, the
>>>> device resets itself. That seemed to not to be solution. What may the
>>>> sloution be?
>>>>
>>>>
> ------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Wait a minute, how does serial communication NOT work during an ISR? I don't think you understand ISRs correctly, or perhaps I just don't understand you.

Step 1: Store all the data you intend to transmit into a global array. Save the size of the data in the array as a global variable. Set up a global pointer to the beginning of this array.
Step 2: Set up a USCI Tx ISR. Have it send the byte of that the pointer is pointing to. Increment the pointer. And decrement the size of the data variable left in the array. If that variable is zero, just put the pointer back to the beginning of the array.
Step 3: In your Timer ISR, have it do the same thing as your USCI Tx ISR.

The USCI Tx ISR gets called every time serial (or SPI, or even I2C) gets transmitted. It is a very code efficient way of transmitting an array of data. Your timer just starts things by sending out the first byte.

This is guaranteed to work unless your Timer gets called more frequently than it takes the processor to transmit that amount of data. If that's the case, clear the Timer interrupt enable in the USCI Tx ISR, but be sure to set it again when you've transmitted your last byte.

-Steve

________________________________
From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of e...@yahoo.com
Sent: Friday, August 28, 2009 4:02 AM
To: m...@yahoogroups.com
Subject: [msp430] Re: Interrupt nesting - msp430f248
Hi,
>I am trying to run a function which uses serial port communication, so serial interrupts, in the timer interrupt service routine. Although the same function works correctly in the main function, it does not do so in the timer isr. I tried to set global interrupt bit(GIE) whether that bit may be reset or not but; after that, the device resets itself. That seemed to not to be solution. What may the sloution be?
>------------------------------------
>
>Hi,
I read the manual of msp430f248 and i know correctly how interrupts work. If i didnt understand it how can i use serial interrupts or timer interrupts which work correctly? Here the non-understood thing is my question. I can already use serial interrupts, e.g. making serial comminucation and printing something on console. In the main code, all initializations are amde for UART and timer modules and also their interrupts are enabled so that; the PC can access the isr of timer module and i can print something while PC is still in the main code. But why can not it print something while it is the isr of timer? I read the manuals and i didnt see anything related to that. Such a problem is an undefined one so; there is not a solution defined that can encounter it. Serial communication does not work in the isr, so that means serial interrupts do not work. I read in the manual that msp430 let interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(comes nonsense to me) while accessing to the isr In fact; i do not preffer making long work like serial communication in the timer isr but the reason for that is as follows. I want msp430 to make serial communication with a slave device and print the data received from it at each 5 seconds. I will do that by timer interrupt. But in that 5 seconds, i want it to be LPM_3 and wake up only for serial communication. I thought maybe it can sleep 5 seconds and in the isr it can make its serial communication. It has nothing else to do in the main code or in other some isr so i thought it wont be a problem to make a long work in the isr of timer. But it seems that strategy doesnt work and i will change it.
[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Al, I agree with you. But I want to tell you a story.

I once saw a program that enabled interrupt from certain hardware-flag. The=
ISR cleared the hardware flag, set a software-flag (which was initially cl=
eared) and returned. The main program pulled and waited for that software-f=
lag, cleared it, and continued. I asked the guy why not simply pull the har=
dware-flag directly. He said he was advised to use interrupt instead of pul=
ling a hardware-flag, and that he should make his ISR as short as possible.

--- In m...@yahoogroups.com, OneStone wrote:
>
> You only think you understand it, but from your response it is=20
> absolutely clear that you have only a vague idea of what is really=20
> happening. The other posters were correct. You should never service an=20
> interrupt from within another interrupt handler unless it is absolutely=20
> unavoidable, and in my 40 years in this industry I can count the number=20
> of times I have found tis to be the case on one hand. You have to=20
> analyse you problem more thoroughly. The purpose of an interrupt is to=20
> recognise that a fast moving event has occurred, so that it doesn't get=20
> lost. To record that event, and perhpas to preserve some data regarding=20
> that event. In the case of a pulse it might be the time at which that=20
> event occurred, be that system time, or real time, or some other time,=20
> or, as in the case of serial communications it might be the received=20
> data itself, or the fact that a byte of data has successfully been=20
> transmitted and the UART is ready for the next byte. NONE of these=20
> things have to be physically executed from the interrupt handler, they=20
> can all be handled from your main routine, the purpose of the interrupt=20
> handler is to trap the event using as little time as possible, so that=20
> other real world events are never missed. If you are sat in one nested=20
> interrupt after another servicing endless depths of nesting you will=20
> miss what is happening in the real world until your program eventually=20
> surfaces for breath.
>=20
> here is a simple pseudo code description of one way to handle interrupts:=
-
>=20
> ORG RAMSTART
>=20
> TASKQ DS 16 ;RESERVE SPACE FOR 16 TASKS
>=20
> ISR1:
> clear the calling flag if not auto cleared
> push service task1 onto task queue
> double increment task pointer
> goto task exit
>=20
> Isr2:
> push service task onto task queue
> double increment task pointer
> task_exit:
> set saved STATUS_REG on STACK to LPM0
> RETI
>=20
> MAINCODE:
> SET LPM3
> TEST_TASK:
> TST TASKPTR
> JZ MAINCODE
> CALL @TASKQ
> CALL TASKDEQ ;REMOVE LAST TASK FROM Q
> (figure this out for yourself)
> JMP TEST_TASK
>=20
> This code only wakes up after an event has pushed a task onto the queue.=
=20
> The oldest task is serviced, but as soon as the device wakes up any=20
> queued interrupts are also serviced, and get the opportunity to push=20
> their own tasks onto the queue. So you get the opportunity to manage=20
> this. First of all you can test if the ISR was called while in sleep=20
> mode, and exit accordingly, then you can adjust stratgey of how you=20
> place the task into the queue based on this. but the key thing is that=20
> this takes place in the foreground, not in the ISR.
>=20
> Obviously this is a simple illustration and not a fully functional,=20
> robust design. When designing a system that handles real world events it=
=20
> is the job of the designer to first of all determine the highest rate=20
> that each ISR will be called at, and, for time constrained inputs, to=20
> determine how long the ISR event is present for, then to design their=20
> ISR handlers in such a way that guarantees that in the worst possible=20
> case, where all interrupts occur sequentially, or at their highest=20
> repetition rates, that none of the events will be missed. Remember that=20
> events are latched by the interrupt handler. The absolute worst strategy=
=20
> to adopt is usually that of nesting isr handlers.
>=20
> Cheers
>=20
> Al
>=20
> jedi_erdi wrote:
> > Hi,
> > I read the manual of msp430f248 and i know correctly how interrupts wor=
k. If i didnt understand it how can i use serial interrupts or timer interr=
upts which work correctly? Here the non-understood thing is my question. I =
can already use serial interrupts, e.g. making serial comminucation and pri=
nting something on console. In the main code, all initializations are amde =
for UART and timer modules and also their interrupts are enabled so that; t=
he PC can access the isr of timer module and i can print something while PC=
is still in the main code. But why can not it print something while it is =
the isr of timer? I read the manuals and i didnt see anything related to th=
at. Such a problem is an undefined one so; there is not a solution defined =
that can encounter it. Serial communication does not work in the isr, so th=
at means serial interrupts do not work. I read in the manual that msp430 le=
t interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is rese=
t(comes nonsense
> to me) while accessing to the isr of timer so; serial interrupts are dis=
abled. Then i tried such a solution that sets the GIE bit in the isr in tim=
er but; that was not a solution as it seems because it resets the device. I=
f a solution to that can not be found; i will do nothing but change my prog=
ram strategy.
> > In fact; i do not preffer making long work like serial communication in=
the timer isr but the reason for that is as follows. I want msp430 to make=
serial communication with a slave device and print the data received from =
it at each 5 seconds. I will do that by timer interrupt. But in that 5 seco=
nds, i want it to be LPM_3 and wake up only for serial communication. I tho=
ught maybe it can sleep 5 seconds and in the isr it can make its serial com=
munication. It has nothing else to do in the main code or in other some isr=
so i thought it wont be a problem to make a long work in the isr of timer.=
But it seems that strategy doesnt work and i will change it.=20
> >=20
> > --- In m...@yahoogroups.com, "tintronic" wrote:
> >> I agree. Nested interrupts should be avoided. I've never had the need =
to do that;I've always found a way around it and it totally depends on the =
application. You might need to change your program strategy.
> >>
> >> As Augusto hinted, the way to do it is keeping the ISRs as short and f=
ast as possible. Anything that doesn't need to be done inside the ISR shoul=
d be signaled to the main loop. For example don't print/send variables from=
within the ISR, instead save the value to a global variable or buffer and =
let the main loop print it.
> >>
> >> But why do you need to enable serial interrupts within the Timer ISR? =
can't you poll the serial flag? Can't you lower the baud rate? doesn't the =
other device have hardware control flow (you can signal the other device no=
t to send data while you're in the Timer ISR)?
> >>
> >> Regards,
> >> Michael K.
> >>
> >> --- In m...@yahoogroups.com, Augusto Einsfeldt wrote:
> >>> You do not understand how interruption works. And seems not understan=
d how serial interface works.
> >>> The MCU reseting after enabling int (GIE=3D1) inside an interrupt ser=
vicing means, probably, that your
> >>> software is loosing the control that result in stack error.
> >>> Enabling the global interrupt inside an interrupt servicing is a comm=
on action to allow the system
> >>> do not loose interrupt events. But, to do this correctly you must und=
erstand how interruption works
> >>> in this microcontroller.
> >>> Read the device user=C2=B4s guide and other books about this subject.=
You must understand this correctly
> >>> before trying to solve this problem. If you solve this by chance or w=
ith some direct help you will
> >>> never understand the topic and will fall in the same or worst situati=
ons in the future.
> >>> One hint: any interrupt service routine must be as short and fast as =
possible. Do not make loops there.
> >>>
> >>> -Augusto
> >>>
> >>>
> >>>
> >>> On Qui 27/08/09 06:52 , erdemdilmen@ sent:
> >>>> Hi,
> >>>> I am trying to run a function which uses serial port communication,
> >>>> so serial interrupts, in the timer interrupt service routine.
> >>>> Although the same function works correctly in the main function, it
> >>>> does not do so in the timer isr. I tried to set global interrupt
> >>>> bit(GIE) whether that bit may be reset or not but; after that, the
> >>>> device resets itself. That seemed to not to be solution. What may th=
e
> >>>> sloution be?
> >>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> >>>>
> >=20
> >=20
> >=20
> >=20
> > ------------------------------------
> >=20
> >
> >=20
> >

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Yes but that says more about the inexperience of the programmer doesn't
it. where does the original hardware flag come from? why couldn't it be
used to trigger the interrupt in the first place? Even if it couldn't it
is obvious with little or no experience required that the interrupt
stage is entirely wasted, and that he has taken a general case and
applied it as an absolute. Every bit of advice is usually a case of ' in
nearly all cases it is better to do it this way'. It is then up to the
user to employ their brain to try and spot the few cases that might be
different.

In this case I would venture that the advisor meant him to have the
hardware flag trigger an interrupt, which he would then have handled by
an ISR, rather than the ass backward way he did it. We can't be
responsible for good advice being applied badly by idiots.

Cheers

Al

old_cow_yellow wrote:
> Al, I agree with you. But I want to tell you a story.
>
> I once saw a program that enabled interrupt from certain
> hardware-flag. The ISR cleared the hardware flag, set a software-flag
> (which was initially cleared) and returned. The main program pulled
> and waited for that software-flag, cleared it, and continued. I asked
> the guy why not simply pull the hardware-flag directly. He said he
> was advised to use interrupt instead of pulling a hardware-flag, and
> that he should make his ISR as short as possible.
>
> --- In m...@yahoogroups.com, OneStone wrote:
>> You only think you understand it, but from your response it is
>> absolutely clear that you have only a vague idea of what is really
>> happening. The other posters were correct. You should never
>> service an interrupt from within another interrupt handler unless
>> it is absolutely unavoidable, and in my 40 years in this industry I
>> can count the number of times I have found tis to be the case on
>> one hand. You have to analyse you problem more thoroughly. The
>> purpose of an interrupt is to recognise that a fast moving event
>> has occurred, so that it doesn't get lost. To record that event,
>> and perhpas to preserve some data regarding that event. In the case
>> of a pulse it might be the time at which that event occurred, be
>> that system time, or real time, or some other time, or, as in the
>> case of serial communications it might be the received data itself,
>> or the fact that a byte of data has successfully been transmitted
>> and the UART is ready for the next byte. NONE of these things have
>> to be physically executed from the interrupt handler, they can all
>> be handled from your main routine, the purpose of the interrupt
>> handler is to trap the event using as little time as possible, so
>> that other real world events are never missed. If you are sat in
>> one nested interrupt after another servicing endless depths of
>> nesting you will miss what is happening in the real world until
>> your program eventually surfaces for breath.
>>
>> here is a simple pseudo code description of one way to handle
>> interrupts:-
>>
>> ORG RAMSTART
>>
>> TASKQ DS 16 ;RESERVE SPACE FOR 16 TASKS
>>
>> ISR1: clear the calling flag if not auto cleared push service task1
>> onto task queue double increment task pointer goto task exit
>>
>> Isr2: push service task onto task queue double increment task
>> pointer task_exit: set saved STATUS_REG on STACK to LPM0 RETI
>>
>> MAINCODE: SET LPM3 TEST_TASK: TST TASKPTR JZ MAINCODE CALL @TASKQ
>> CALL TASKDEQ ;REMOVE LAST TASK FROM Q (figure this out for
>> yourself) JMP TEST_TASK
>>
>> This code only wakes up after an event has pushed a task onto the
>> queue. The oldest task is serviced, but as soon as the device wakes
>> up any queued interrupts are also serviced, and get the opportunity
>> to push their own tasks onto the queue. So you get the opportunity
>> to manage this. First of all you can test if the ISR was called
>> while in sleep mode, and exit accordingly, then you can adjust
>> stratgey of how you place the task into the queue based on this.
>> but the key thing is that this takes place in the foreground, not
>> in the ISR.
>>
>> Obviously this is a simple illustration and not a fully functional,
>> robust design. When designing a system that handles real world
>> events it is the job of the designer to first of all determine the
>> highest rate that each ISR will be called at, and, for time
>> constrained inputs, to determine how long the ISR event is present
>> for, then to design their ISR handlers in such a way that
>> guarantees that in the worst possible case, where all interrupts
>> occur sequentially, or at their highest repetition rates, that none
>> of the events will be missed. Remember that events are latched by
>> the interrupt handler. The absolute worst strategy to adopt is
>> usually that of nesting isr handlers.
>>
>> Cheers
>>
>> Al
>>
>> jedi_erdi wrote:
>>> Hi, I read the manual of msp430f248 and i know correctly how
>>> interrupts work. If i didnt understand it how can i use serial
>>> interrupts or timer interrupts which work correctly? Here the
>>> non-understood thing is my question. I can already use serial
>>> interrupts, e.g. making serial comminucation and printing
>>> something on console. In the main code, all initializations are
>>> amde for UART and timer modules and also their interrupts are
>>> enabled so that; the PC can access the isr of timer module and i
>>> can print something while PC is still in the main code. But why
>>> can not it print something while it is the isr of timer? I read
>>> the manuals and i didnt see anything related to that. Such a
>>> problem is an undefined one so; there is not a solution defined
>>> that can encounter it. Serial communication does not work in the
>>> isr, so that means serial interrupts do not work. I read in the
>>> manual that msp430 let interrupt nesting if GIE bit is set. I
>>> thought, maybe the GIE bit is reset(comes nonsense
>> to me) while accessing to the isr of timer so; serial interrupts
>> are disabled. Then i tried such a solution that sets the GIE bit in
>> the isr in timer but; that was not a solution as it seems because
>> it resets the device. If a solution to that can not be found; i
>> will do nothing but change my program strategy.
>>> In fact; i do not preffer making long work like serial
>>> communication in the timer isr but the reason for that is as
>>> follows. I want msp430 to make serial communication with a slave
>>> device and print the data received from it at each 5 seconds. I
>>> will do that by timer interrupt. But in that 5 seconds, i want it
>>> to be LPM_3 and wake up only for serial communication. I thought
>>> maybe it can sleep 5 seconds and in the isr it can make its
>>> serial communication. It has nothing else to do in the main code
>>> or in other some isr so i thought it wont be a problem to make a
>>> long work in the isr of timer. But it seems that strategy doesnt
>>> work and i will change it.
>>>
>>> --- In m...@yahoogroups.com, "tintronic" wrote:
>>>> I agree. Nested interrupts should be avoided. I've never had
>>>> the need to do that;I've always found a way around it and it
>>>> totally depends on the application. You might need to change
>>>> your program strategy.
>>>>
>>>> As Augusto hinted, the way to do it is keeping the ISRs as
>>>> short and fast as possible. Anything that doesn't need to be
>>>> done inside the ISR should be signaled to the main loop. For
>>>> example don't print/send variables from within the ISR, instead
>>>> save the value to a global variable or buffer and let the main
>>>> loop print it.
>>>>
>>>> But why do you need to enable serial interrupts within the
>>>> Timer ISR? can't you poll the serial flag? Can't you lower the
>>>> baud rate? doesn't the other device have hardware control flow
>>>> (you can signal the other device not to send data while you're
>>>> in the Timer ISR)?
>>>>
>>>> Regards, Michael K.
>>>>
>>>> --- In m...@yahoogroups.com, Augusto Einsfeldt wrote:
>>>>> You do not understand how interruption works. And seems not
>>>>> understand how serial interface works. The MCU reseting after
>>>>> enabling int (GIE=1) inside an interrupt servicing means,
>>>>> probably, that your software is loosing the control that
>>>>> result in stack error. Enabling the global interrupt inside
>>>>> an interrupt servicing is a common action to allow the system
>>>>> do not loose interrupt events. But, to do this correctly you
>>>>> must understand how interruption works in this
>>>>> microcontroller. Read the device user´s guide and other
>>>>> books about this subject. You must understand this correctly
>>>>> before trying to solve this problem. If you solve this by
>>>>> chance or with some direct help you will never understand the
>>>>> topic and will fall in the same or worst situations in the
>>>>> future. One hint: any interrupt service routine must be as
>>>>> short and fast as possible. Do not make loops there.
>>>>>
>>>>> -Augusto
>>>>>
>>>>>
>>>>>
>>>>> On Qui 27/08/09 06:52 , erdemdilmen@ sent:
>>>>>> Hi, I am trying to run a function which uses serial port
>>>>>> communication, so serial interrupts, in the timer interrupt
>>>>>> service routine. Although the same function works correctly
>>>>>> in the main function, it does not do so in the timer isr. I
>>>>>> tried to set global interrupt bit(GIE) whether that bit may
>>>>>> be reset or not but; after that, the device resets itself.
>>>>>> That seemed to not to be solution. What may the sloution
>>>>>> be?
>>>>>>
>>>>>>
>>>
>>>
>>>
>>> ------------------------------------
>>>
>>>
>>>
>>>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Your reply shows that you don't know neither how the interrupt hardware wor=
ks nor what interrupts are meant to do or handled.

> I read the manual of msp430f248 and i know correctly how interrupts
> work. If i didnt understand it how can i use serial interrupts or
> timer interrupts which work correctly?
You can also real your cars manual and drive around your block without caus=
ing an accident. That doesn't mean you know how to drive. (Your block may n=
ot have any semaphores)

> I thought, maybe the GIE bit is reset(comes nonsense to me) while
> accessing to the isr of timer so; serial interrupts are disabled.
It's NOT nonsense. I don't know a microcontroller that doesn't disable GIE =
when the PC jumps to an interrupt vector (when triggered by the interrupt o=
f course). Take another look at the MSP430x2xx user's guide under 2.2.3 "In=
terrupt Processing". I quote step 6 of the interrupt logic flow:
"6) The SR is cleared. This terminates any low-power mode. Because the GIE =
bit is cleared, further interrupts are disabled."

> In the main code, all initializations are amde for UART and timer
> modules and also their interrupts are enabled so that; the PC can
> access the isr of timer module and i can print something while PC
> is still in the main code. But why can not it print something while
> it is the isr of timer?
That only means you cannot print. You can only conclude that probably (but =
not necessary) it's because your print function uses interrupts. Do you kno=
w how the print function works? Did you write it, did you just copy/pasted =
a print code or are you using the print function provided by a library ? Do=
a manual printing routine that doesn't use interrupts and it will work jus=
t fine.

> Serial communication does not work in the isr, so that means serial
> interrupts do not work.
No. You only know that your print functions doesn't send data throught the =
serial port, not that the serial port doesn't work. It's rather the other w=
ay around: Your print uses interrupts, so your print doesn't work in the IS=
R which means no data can be sent in the ISR.

> I want msp430 to make serial communication with a slave device and
> print the data received from it at each 5 seconds. I will do that
> by timer interrupt. But in that 5 seconds, i want it to be LPM_3
> and wake up only for serial communication. I thought maybe it can
> sleep 5 seconds and in the isr it can make its serial
> communication. It has nothing else to do in the main code or in
> other some isr so i thought it wont be a problem to make a long
> work in the isr of timer. But it seems that strategy doesnt work
> and i will change it.=20
So the only purpose of the timer is to exit the processor from sleep state.=
Then let the timer ISR only do that:

void main(void)
{
initialization();
for (;;) // main loop
{
communicate_with_slave();
print_data();
LPM3; //Sleep until timer disables sleep
}
}

__interrupt void timer_ISR(void)
{
__low_power_mode_off_on_exit() ;
}

this pseudo code should work with your current print function.

Regards,
Michael K.

--- In m...@yahoogroups.com, "jedi_erdi" wrote:
>
> Hi,
> I read the manual of msp430f248 and i know correctly how interrupts work.=
If i didnt understand it how can i use serial interrupts or timer interrup=
ts which work correctly? Here the non-understood thing is my question. I ca=
n already use serial interrupts, e.g. making serial comminucation and print=
ing something on console. In the main code, all initializations are amde fo=
r UART and timer modules and also their interrupts are enabled so that; the=
PC can access the isr of timer module and i can print something while PC i=
s still in the main code. But why can not it print something while it is th=
e isr of timer? I read the manuals and i didnt see anything related to that=
. Such a problem is an undefined one so; there is not a solution defined th=
at can encounter it. Serial communication does not work in the isr, so that=
means serial interrupts do not work. I read in the manual that msp430 let =
interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(=
comes nonsense to me) while accessing to the isr of timer so; serial interr=
upts are disabled. Then i tried such a solution that sets the GIE bit in th=
e isr in timer but; that was not a solution as it seems because it resets t=
he device. If a solution to that can not be found; i will do nothing but ch=
ange my program strategy.
> In fact; i do not preffer making long work like serial communication in t=
he timer isr but the reason for that is as follows. I want msp430 to make s=
erial communication with a slave device and print the data received from it=
at each 5 seconds. I will do that by timer interrupt. But in that 5 second=
s, i want it to be LPM_3 and wake up only for serial communication. I thoug=
ht maybe it can sleep 5 seconds and in the isr it can make its serial commu=
nication. It has nothing else to do in the main code or in other some isr s=
o i thought it wont be a problem to make a long work in the isr of timer. B=
ut it seems that strategy doesnt work and i will change it.=20
>=20
> --- In m...@yahoogroups.com, "tintronic" wrote:
> >
> > I agree. Nested interrupts should be avoided. I've never had the need t=
o do that;I've always found a way around it and it totally depends on the a=
pplication. You might need to change your program strategy.
> >=20
> > As Augusto hinted, the way to do it is keeping the ISRs as short and fa=
st as possible. Anything that doesn't need to be done inside the ISR should=
be signaled to the main loop. For example don't print/send variables from =
within the ISR, instead save the value to a global variable or buffer and l=
et the main loop print it.
> >=20
> > But why do you need to enable serial interrupts within the Timer ISR? c=
an't you poll the serial flag? Can't you lower the baud rate? doesn't the o=
ther device have hardware control flow (you can signal the other device not=
to send data while you're in the Timer ISR)?
> >=20
> > Regards,
> > Michael K.
> >=20
> > --- In m...@yahoogroups.com, Augusto Einsfeldt wrote:
> > >
> > > You do not understand how interruption works. And seems not understan=
d how serial interface works.
> > > The MCU reseting after enabling int (GIE=3D1) inside an interrupt ser=
vicing means, probably, that your
> > > software is loosing the control that result in stack error.
> > > Enabling the global interrupt inside an interrupt servicing is a comm=
on action to allow the system
> > > do not loose interrupt events. But, to do this correctly you must und=
erstand how interruption works
> > > in this microcontroller.
> > > Read the device user=C2=B4s guide and other books about this subject.=
You must understand this correctly
> > > before trying to solve this problem. If you solve this by chance or w=
ith some direct help you will
> > > never understand the topic and will fall in the same or worst situati=
ons in the future.
> > > One hint: any interrupt service routine must be as short and fast as =
possible. Do not make loops there.
> > >=20
> > > -Augusto
> > >=20
> > >=20
> > >=20
> > > On Qui 27/08/09 06:52 , erdemdilmen@ sent:
> > > > Hi,
> > > > I am trying to run a function which uses serial port communication,
> > > > so serial interrupts, in the timer interrupt service routine.
> > > > Although the same function works correctly in the main function, it
> > > > does not do so in the timer isr. I tried to set global interrupt
> > > > bit(GIE) whether that bit may be reset or not but; after that, the
> > > > device resets itself. That seemed to not to be solution. What may t=
he
> > > > sloution be?
> > > >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
> > > >
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi to all,
I changed my strategy and now i am not doing the work in the timer isr but; doing it in the main routine. I used software flags which are used as the states of the program flow in the main routine. My problem has been solved. Thanks for all solution suggestions but some misunderstandings happened.
Tintronic wrote:
"> I read the manual of msp430f248 and i know correctly how interrupts
> work. If i didnt understand it how can i use serial interrupts or
> timer interrupts which work correctly?
You can also real your cars manual and drive around your block without causing an accident. That doesn't mean you know how to drive. (Your block may not have any semaphores)"
Before strating to work on timer module i have already used serial communication which uses Rx and Tx interrupts successfully so that means; my serial interrupts are correct.
Well, i can say -i can also real my car and drive it around my block without accident- because; i have already drived it before and it was successfull, that is the reason for me to be sure about my Rx and Tx interrupts work correctly.
--
--
> I thought, maybe the GIE bit is reset(comes nonsense to me) while
> accessing to the isr of timer so; serial interrupts are disabled.
It's NOT nonsense. I don't know a microcontroller that doesn't disable GIE when the PC jumps to an interrupt vector (when triggered by the interrupt of course).
Take another look at the MSP430x2xx user's guide under 2.2.3 "Interrupt Processing". I quote step 6 of the interrupt logic flow:
"6) The SR is cleared. This terminates any low-power mode. Because the GIE bit is cleared, further interrupts are disabled."
I read the manual,slau144e.pdf, and on the page 33 of it there writes:
"Interrupt nesting is enabled if the GIE bit is set inside an interrupt service routine. When interrupt nesting is enabled, any interrupt occurring during an interrupt service routine will interrupt the routine, regardless of the interrupt priorities."
So it is obvious that interrupt nesting is possible. It came nonse to me that GIE bit will be reset because i have never read such a thimg on that manual. I tried to again set the GIE bit in the timer ISR but;
serial interrupts didnt work. After that, i thought, "although it is written in the manual that; interrupt nesting is possible why can not i nest interrupts??" Maybe that is not so important because
i am now already not nesting interrupts but when i encountered that problem, it came interesting to me so i shared it with forum.
--
--
> Serial communication does not work in the isr, so that means serial
> interrupts do not work.
No. You only know that your print functions doesn't send data throught the serial port, not that the serial port doesn't work. It's rather the other way around: Your print uses interrupts, so your print doesn't work in the ISR which means no data can be sent in the ISR.
As printf function does not work in timer isr, RX and TX isr could not work either because; i used such function that communicates serially with the slave device. It was so obvious that;
msp430 could not communicate with slave device using serial interrupts while it is in the timer isr. I read in the manul that interrupt nesting is possible and i saw that serial interrupts didnt work in the timer isr. After that conflict between practice and the manual, that problem came interesting to me, my all stuff was that, i wanted to share with forum.
Anyway, i already have my solution now and my system works correctly. I agree with you too that in isr long works must be avoided and only software flags maybe set to effect the program flow of the main routine.

--- In m...@yahoogroups.com, "Hayashi, Steve" wrote:
>
> Wait a minute, how does serial communication NOT work during an ISR? I don't think you understand ISRs correctly, or perhaps I just don't understand you.
>
> Step 1: Store all the data you intend to transmit into a global array. Save the size of the data in the array as a global variable. Set up a global pointer to the beginning of this array.
> Step 2: Set up a USCI Tx ISR. Have it send the byte of that the pointer is pointing to. Increment the pointer. And decrement the size of the data variable left in the array. If that variable is zero, just put the pointer back to the beginning of the array.
> Step 3: In your Timer ISR, have it do the same thing as your USCI Tx ISR.
>
> The USCI Tx ISR gets called every time serial (or SPI, or even I2C) gets transmitted. It is a very code efficient way of transmitting an array of data. Your timer just starts things by sending out the first byte.
>
> This is guaranteed to work unless your Timer gets called more frequently than it takes the processor to transmit that amount of data. If that's the case, clear the Timer interrupt enable in the USCI Tx ISR, but be sure to set it again when you've transmitted your last byte.
>
> -Steve
>
> ________________________________
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of erdemdilmen@...
> Sent: Friday, August 28, 2009 4:02 AM
> To: m...@yahoogroups.com
> Subject: [msp430] Re: Interrupt nesting - msp430f248
> Hi,
> >I am trying to run a function which uses serial port communication, so serial interrupts, in the timer interrupt service routine. Although the same function works correctly in the main function, it does not do so in the timer isr. I tried to set global interrupt bit(GIE) whether that bit may be reset or not but; after that, the device resets itself. That seemed to not to be solution. What may the sloution be?
> >------------------------------------
> >
> >Hi,
> I read the manual of msp430f248 and i know correctly how interrupts work. If i didnt understand it how can i use serial interrupts or timer interrupts which work correctly? Here the non-understood thing is my question. I can already use serial interrupts, e.g. making serial comminucation and printing something on console. In the main code, all initializations are amde for UART and timer modules and also their interrupts are enabled so that; the PC can access the isr of timer module and i can print something while PC is still in the main code. But why can not it print something while it is the isr of timer? I read the manuals and i didnt see anything related to that. Such a problem is an undefined one so; there is not a solution defined that can encounter it. Serial communication does not work in the isr, so that means serial interrupts do not work. I read in the manual that msp430 let interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(comes nonsense to me) while accessing to the isr In fact; i do not preffer making long work like serial communication in the timer isr but the reason for that is as follows. I want msp430 to make serial communication with a slave device and print the data received from it at each 5 seconds. I will do that by timer interrupt. But in that 5 seconds, i want it to be LPM_3 and wake up only for serial communication. I thought maybe it can sleep 5 seconds and in the isr it can make its serial communication. It has nothing else to do in the main code or in other some isr so i thought it wont be a problem to make a long work in the isr of timer. But it seems that strategy doesnt work and i will change it.
> [Non-text portions of this message have been removed]
>
------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Software flags are only one solution, but pften not the best. try
looking at a task queue. It is more flexible, and more efficient.

Al

jedi_erdi wrote:
> Hi to all,
> I changed my strategy and now i am not doing the work in the timer isr but; doing it in the main routine. I used software flags which are used as the states of the program flow in the main routine. My problem has been solved. Thanks for all solution suggestions but some misunderstandings happened.
> Tintronic wrote:
> "> I read the manual of msp430f248 and i know correctly how interrupts
>> work. If i didnt understand it how can i use serial interrupts or
>> timer interrupts which work correctly?
> You can also real your cars manual and drive around your block without causing an accident. That doesn't mean you know how to drive. (Your block may not have any semaphores)"
> Before strating to work on timer module i have already used serial communication which uses Rx and Tx interrupts successfully so that means; my serial interrupts are correct.
> Well, i can say -i can also real my car and drive it around my block without accident- because; i have already drived it before and it was successfull, that is the reason for me to be sure about my Rx and Tx interrupts work correctly.
> --
> --
>> I thought, maybe the GIE bit is reset(comes nonsense to me) while
>> accessing to the isr of timer so; serial interrupts are disabled.
> It's NOT nonsense. I don't know a microcontroller that doesn't disable GIE when the PC jumps to an interrupt vector (when triggered by the interrupt of course).
> Take another look at the MSP430x2xx user's guide under 2.2.3 "Interrupt Processing". I quote step 6 of the interrupt logic flow:
> "6) The SR is cleared. This terminates any low-power mode. Because the GIE bit is cleared, further interrupts are disabled."
> I read the manual,slau144e.pdf, and on the page 33 of it there writes:
> "Interrupt nesting is enabled if the GIE bit is set inside an interrupt service routine. When interrupt nesting is enabled, any interrupt occurring during an interrupt service routine will interrupt the routine, regardless of the interrupt priorities."
> So it is obvious that interrupt nesting is possible. It came nonse to me that GIE bit will be reset because i have never read such a thimg on that manual. I tried to again set the GIE bit in the timer ISR but;
> serial interrupts didnt work. After that, i thought, "although it is written in the manual that; interrupt nesting is possible why can not i nest interrupts??" Maybe that is not so important because
> i am now already not nesting interrupts but when i encountered that problem, it came interesting to me so i shared it with forum.
> --
> --
>> Serial communication does not work in the isr, so that means serial
>> interrupts do not work.
> No. You only know that your print functions doesn't send data throught the serial port, not that the serial port doesn't work. It's rather the other way around: Your print uses interrupts, so your print doesn't work in the ISR which means no data can be sent in the ISR.
> As printf function does not work in timer isr, RX and TX isr could not work either because; i used such function that communicates serially with the slave device. It was so obvious that;
> msp430 could not communicate with slave device using serial interrupts while it is in the timer isr. I read in the manul that interrupt nesting is possible and i saw that serial interrupts didnt work in the timer isr. After that conflict between practice and the manual, that problem came interesting to me, my all stuff was that, i wanted to share with forum.
> Anyway, i already have my solution now and my system works correctly. I agree with you too that in isr long works must be avoided and only software flags maybe set to effect the program flow of the main routine.
>
> --- In m...@yahoogroups.com, "Hayashi, Steve" wrote:
>> Wait a minute, how does serial communication NOT work during an ISR? I don't think you understand ISRs correctly, or perhaps I just don't understand you.
>>
>> Step 1: Store all the data you intend to transmit into a global array. Save the size of the data in the array as a global variable. Set up a global pointer to the beginning of this array.
>> Step 2: Set up a USCI Tx ISR. Have it send the byte of that the pointer is pointing to. Increment the pointer. And decrement the size of the data variable left in the array. If that variable is zero, just put the pointer back to the beginning of the array.
>> Step 3: In your Timer ISR, have it do the same thing as your USCI Tx ISR.
>>
>> The USCI Tx ISR gets called every time serial (or SPI, or even I2C) gets transmitted. It is a very code efficient way of transmitting an array of data. Your timer just starts things by sending out the first byte.
>>
>> This is guaranteed to work unless your Timer gets called more frequently than it takes the processor to transmit that amount of data. If that's the case, clear the Timer interrupt enable in the USCI Tx ISR, but be sure to set it again when you've transmitted your last byte.
>>
>> -Steve
>>
>> ________________________________
>> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of erdemdilmen@...
>> Sent: Friday, August 28, 2009 4:02 AM
>> To: m...@yahoogroups.com
>> Subject: [msp430] Re: Interrupt nesting - msp430f248
>> Hi,
>>> I am trying to run a function which uses serial port communication, so serial interrupts, in the timer interrupt service routine. Although the same function works correctly in the main function, it does not do so in the timer isr. I tried to set global interrupt bit(GIE) whether that bit may be reset or not but; after that, the device resets itself. That seemed to not to be solution. What may the sloution be?
>>> ------------------------------------
>>>
>>> Hi,
>> I read the manual of msp430f248 and i know correctly how interrupts work. If i didnt understand it how can i use serial interrupts or timer interrupts which work correctly? Here the non-understood thing is my question. I can already use serial interrupts, e.g. making serial comminucation and printing something on console. In the main code, all initializations are amde for UART and timer modules and also their interrupts are enabled so that; the PC can access the isr of timer module and i can print something while PC is still in the main code. But why can not it print something while it is the isr of timer? I read the manuals and i didnt see anything related to that. Such a problem is an undefined one so; there is not a solution defined that can encounter it. Serial communication does not work in the isr, so that means serial interrupts do not work. I read in the manual that msp430 let interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(comes nonsens
e to me) while accessing to the isr In fact; i do not preffer making long work like serial communication in the timer isr but the reason for that is as follows. I want msp430 to make serial communication with a slave device and print the data received from it at each 5 seconds. I will do that by timer interrupt. But in that 5 seconds, i want it to be LPM_3 and wake up only for serial communication. I thought maybe it can sleep 5 seconds and in the isr it can make its serial communication. It has nothing else to do in the main code or in other some isr so i thought it wont be a problem to make a long work in the isr of timer. But it seems that strategy doesnt work and i will change it.
>> [Non-text portions of this message have been removed]
>>
> ------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

It just so happens that on Wednesday, for the first time ever, I needed to enable nested interrupts. While I was enabling GIE within TimerB_ISR, a question interrupted my train of tought:
In the TimerA_ISR, did you disable the TimerA IE or cleared IFG before setting GIE? Otherwise the TimerA_ISR would have been called again right after enabling GIE. This means you would have had an infinite nesting of TimerA_ISR untill your stack overflowed and started messing up your entire RAM content (and maybe some SFR too). This would explain why you could never print (TimerA_ISR would never have arrived to the print instruction).

My problem was that TimerA_ISR had to had a higher priority than TimerB_ISR, but ISR priorities are hardwired into the MSP430. The problem occurred that when 3 TimerB interrupts coincided, one of the much higher frequency TimerA interrupts was missed. TimerB_ISR is already stripped to the minimum.

So I only had to add 4 lines to my TimerB_ISR (and create two 4-line enable/disable functions). These were:

__interrupt void TimerB_ISR (void)
{
Disable_TB_ints(); // Added this to avoid TimerB_ISR self-nesting
_EINT(); // Enable GIE
...
switch (TBIV)
(servicing of the interrupt)
...
_DINT(); // Disable GIE (back to normal) to avoid self-nesting
Enable_TB_ints(); // Re-enable TimerB interrupts
}

I solved my TimerA_ISR attending problem and didn't have any additional problem (other than foregetting to put the _DINT() instruction). I increased the stack size just in case, since I effectively created an additional nesting layer (now timerB ISR will sometimes be pushed onto the stack).

Out of pure academic excercise, you might want to check this in your old ISR and see if now your print function works.

> > Well, i can say -i can also real my car and drive it around my
> > block without accident- because; i have already drived it before
> > and it was successfull, that is the reason for me to be sure about
> > my Rx and Tx interrupts work correctly.

My point was not on your Rx and Tx routines, but in your statement:

> > I read the manual of msp430f248 and i know correctly how
> > interrupts work. If i didnt understand it how can i use serial
> > interrupts or timer interrupts which work correctly?
> > As printf function does not work in timer isr, RX and TX isr could
> > not work either because; i used such function that communicates
> > serially with the slave device. It was so obvious that;
> > msp430 could not communicate with slave device using serial
> > interrupts while it is in the timer isr.
You didn't write that in your post, you wrote:
> Serial communication does not work in the isr, so that means serial
> interrupts do not work.
My point is that serial communication does work on the hardware level, and that your problem was the print function which uses the serial port, not the serial port itself.

Hope my case helps you with your original nesting problem.

Regards,
Michael K.

--- In m...@yahoogroups.com, "jedi_erdi" wrote:
>
> Hi to all,
> I changed my strategy and now i am not doing the work in the timer isr but; doing it in the main routine. I used software flags which are used as the states of the program flow in the main routine. My problem has been solved. Thanks for all solution suggestions but some misunderstandings happened.
> Tintronic wrote:
> "> I read the manual of msp430f248 and i know correctly how interrupts
> > work. If i didnt understand it how can i use serial interrupts or
> > timer interrupts which work correctly?
> You can also real your cars manual and drive around your block without causing an accident. That doesn't mean you know how to drive. (Your block may not have any semaphores)"
> Before strating to work on timer module i have already used serial communication which uses Rx and Tx interrupts successfully so that means; my serial interrupts are correct.
> Well, i can say -i can also real my car and drive it around my block without accident- because; i have already drived it before and it was successfull, that is the reason for me to be sure about my Rx and Tx interrupts work correctly.
> --
> --
> > I thought, maybe the GIE bit is reset(comes nonsense to me) while
> > accessing to the isr of timer so; serial interrupts are disabled.
> It's NOT nonsense. I don't know a microcontroller that doesn't disable GIE when the PC jumps to an interrupt vector (when triggered by the interrupt of course).
> Take another look at the MSP430x2xx user's guide under 2.2.3 "Interrupt Processing". I quote step 6 of the interrupt logic flow:
> "6) The SR is cleared. This terminates any low-power mode. Because the GIE bit is cleared, further interrupts are disabled."
> I read the manual,slau144e.pdf, and on the page 33 of it there writes:
> "Interrupt nesting is enabled if the GIE bit is set inside an interrupt service routine. When interrupt nesting is enabled, any interrupt occurring during an interrupt service routine will interrupt the routine, regardless of the interrupt priorities."
> So it is obvious that interrupt nesting is possible. It came nonse to me that GIE bit will be reset because i have never read such a thimg on that manual. I tried to again set the GIE bit in the timer ISR but;
> serial interrupts didnt work. After that, i thought, "although it is written in the manual that; interrupt nesting is possible why can not i nest interrupts??" Maybe that is not so important because
> i am now already not nesting interrupts but when i encountered that problem, it came interesting to me so i shared it with forum.
> --
> --
> > Serial communication does not work in the isr, so that means serial
> > interrupts do not work.
> No. You only know that your print functions doesn't send data throught the serial port, not that the serial port doesn't work. It's rather the other way around: Your print uses interrupts, so your print doesn't work in the ISR which means no data can be sent in the ISR.
> As printf function does not work in timer isr, RX and TX isr could not work either because; i used such function that communicates serially with the slave device. It was so obvious that;
> msp430 could not communicate with slave device using serial interrupts while it is in the timer isr. I read in the manul that interrupt nesting is possible and i saw that serial interrupts didnt work in the timer isr. After that conflict between practice and the manual, that problem came interesting to me, my all stuff was that, i wanted to share with forum.
> Anyway, i already have my solution now and my system works correctly. I agree with you too that in isr long works must be avoided and only software flags maybe set to effect the program flow of the main routine.
>
> --- In m...@yahoogroups.com, "Hayashi, Steve" wrote:
> >
> > Wait a minute, how does serial communication NOT work during an ISR? I don't think you understand ISRs correctly, or perhaps I just don't understand you.
> >
> > Step 1: Store all the data you intend to transmit into a global array. Save the size of the data in the array as a global variable. Set up a global pointer to the beginning of this array.
> > Step 2: Set up a USCI Tx ISR. Have it send the byte of that the pointer is pointing to. Increment the pointer. And decrement the size of the data variable left in the array. If that variable is zero, just put the pointer back to the beginning of the array.
> > Step 3: In your Timer ISR, have it do the same thing as your USCI Tx ISR.
> >
> > The USCI Tx ISR gets called every time serial (or SPI, or even I2C) gets transmitted. It is a very code efficient way of transmitting an array of data. Your timer just starts things by sending out the first byte.
> >
> > This is guaranteed to work unless your Timer gets called more frequently than it takes the processor to transmit that amount of data. If that's the case, clear the Timer interrupt enable in the USCI Tx ISR, but be sure to set it again when you've transmitted your last byte.
> >
> > -Steve
> >
> > ________________________________
> > From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of erdemdilmen@
> > Sent: Friday, August 28, 2009 4:02 AM
> > To: m...@yahoogroups.com
> > Subject: [msp430] Re: Interrupt nesting - msp430f248
> >
> >
> >
> >
> > Hi,
> > >I am trying to run a function which uses serial port communication, so serial interrupts, in the timer interrupt service routine. Although the same function works correctly in the main function, it does not do so in the timer isr. I tried to set global interrupt bit(GIE) whether that bit may be reset or not but; after that, the device resets itself. That seemed to not to be solution. What may the sloution be?
> > >------------------------------------
> > >
> > >Hi,
> > I read the manual of msp430f248 and i know correctly how interrupts work. If i didnt understand it how can i use serial interrupts or timer interrupts which work correctly? Here the non-understood thing is my question. I can already use serial interrupts, e.g. making serial comminucation and printing something on console. In the main code, all initializations are amde for UART and timer modules and also their interrupts are enabled so that; the PC can access the isr of timer module and i can print something while PC is still in the main code. But why can not it print something while it is the isr of timer? I read the manuals and i didnt see anything related to that. Such a problem is an undefined one so; there is not a solution defined that can encounter it. Serial communication does not work in the isr, so that means serial interrupts do not work. I read in the manual that msp430 let interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(comes nonsense to me) while accessing to the isr In fact; i do not preffer making long work like serial communication in the timer isr but the reason for that is as follows. I want msp430 to make serial communication with a slave device and print the data received from it at each 5 seconds. I will do that by timer interrupt. But in that 5 seconds, i want it to be LPM_3 and wake up only for serial communication. I thought maybe it can sleep 5 seconds and in the isr it can make its serial communication. It has nothing else to do in the main code or in other some isr so i thought it wont be a problem to make a long work in the isr of timer. But it seems that strategy doesnt work and i will change it.
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
>

------------------------------------

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Perhaps I am cocky. When I feel there is a need to, I never hesitate to enable GIE inside ISR because I know precisely what it does and what the consequences are. I do hesitate to use things like printf() inside ISR -- with or without GIE. I do not know (nor care to know) whether these things are re-entrant or how long do they take to execute.

--- In m...@yahoogroups.com, "tintronic" wrote:
>
> It just so happens that on Wednesday, for the first time ever, I needed to enable nested interrupts. While I was enabling GIE within TimerB_ISR, a question interrupted my train of tought:
> In the TimerA_ISR, did you disable the TimerA IE or cleared IFG before setting GIE? Otherwise the TimerA_ISR would have been called again right after enabling GIE. This means you would have had an infinite nesting of TimerA_ISR untill your stack overflowed and started messing up your entire RAM content (and maybe some SFR too). This would explain why you could never print (TimerA_ISR would never have arrived to the print instruction).
>
> My problem was that TimerA_ISR had to had a higher priority than TimerB_ISR, but ISR priorities are hardwired into the MSP430. The problem occurred that when 3 TimerB interrupts coincided, one of the much higher frequency TimerA interrupts was missed. TimerB_ISR is already stripped to the minimum.
>
> So I only had to add 4 lines to my TimerB_ISR (and create two 4-line enable/disable functions). These were:
>
> __interrupt void TimerB_ISR (void)
> {
> Disable_TB_ints(); // Added this to avoid TimerB_ISR self-nesting
> _EINT(); // Enable GIE
> ...
> switch (TBIV)
> (servicing of the interrupt)
> ...
> _DINT(); // Disable GIE (back to normal) to avoid self-nesting
> Enable_TB_ints(); // Re-enable TimerB interrupts
> }
>
> I solved my TimerA_ISR attending problem and didn't have any additional problem (other than foregetting to put the _DINT() instruction). I increased the stack size just in case, since I effectively created an additional nesting layer (now timerB ISR will sometimes be pushed onto the stack).
>
> Out of pure academic excercise, you might want to check this in your old ISR and see if now your print function works.
>
> > > Well, i can say -i can also real my car and drive it around my
> > > block without accident- because; i have already drived it before
> > > and it was successfull, that is the reason for me to be sure about
> > > my Rx and Tx interrupts work correctly.
>
> My point was not on your Rx and Tx routines, but in your statement:
>
> > > I read the manual of msp430f248 and i know correctly how
> > > interrupts work. If i didnt understand it how can i use serial
> > > interrupts or timer interrupts which work correctly?
> > > As printf function does not work in timer isr, RX and TX isr could
> > > not work either because; i used such function that communicates
> > > serially with the slave device. It was so obvious that;
> > > msp430 could not communicate with slave device using serial
> > > interrupts while it is in the timer isr.
> You didn't write that in your post, you wrote:
> > Serial communication does not work in the isr, so that means serial
> > interrupts do not work.
> My point is that serial communication does work on the hardware level, and that your problem was the print function which uses the serial port, not the serial port itself.
>
> Hope my case helps you with your original nesting problem.
>
> Regards,
> Michael K.
>
> --- In m...@yahoogroups.com, "jedi_erdi" wrote:
> >
> > Hi to all,
> > I changed my strategy and now i am not doing the work in the timer isr but; doing it in the main routine. I used software flags which are used as the states of the program flow in the main routine. My problem has been solved. Thanks for all solution suggestions but some misunderstandings happened.
> > Tintronic wrote:
> > "> I read the manual of msp430f248 and i know correctly how interrupts
> > > work. If i didnt understand it how can i use serial interrupts or
> > > timer interrupts which work correctly?
> > You can also real your cars manual and drive around your block without causing an accident. That doesn't mean you know how to drive. (Your block may not have any semaphores)"
> > Before strating to work on timer module i have already used serial communication which uses Rx and Tx interrupts successfully so that means; my serial interrupts are correct.
> > Well, i can say -i can also real my car and drive it around my block without accident- because; i have already drived it before and it was successfull, that is the reason for me to be sure about my Rx and Tx interrupts work correctly.
> > --
> > --
> > > I thought, maybe the GIE bit is reset(comes nonsense to me) while
> > > accessing to the isr of timer so; serial interrupts are disabled.
> > It's NOT nonsense. I don't know a microcontroller that doesn't disable GIE when the PC jumps to an interrupt vector (when triggered by the interrupt of course).
> > Take another look at the MSP430x2xx user's guide under 2.2.3 "Interrupt Processing". I quote step 6 of the interrupt logic flow:
> > "6) The SR is cleared. This terminates any low-power mode. Because the GIE bit is cleared, further interrupts are disabled."
> > I read the manual,slau144e.pdf, and on the page 33 of it there writes:
> > "Interrupt nesting is enabled if the GIE bit is set inside an interrupt service routine. When interrupt nesting is enabled, any interrupt occurring during an interrupt service routine will interrupt the routine, regardless of the interrupt priorities."
> > So it is obvious that interrupt nesting is possible. It came nonse to me that GIE bit will be reset because i have never read such a thimg on that manual. I tried to again set the GIE bit in the timer ISR but;
> > serial interrupts didnt work. After that, i thought, "although it is written in the manual that; interrupt nesting is possible why can not i nest interrupts??" Maybe that is not so important because
> > i am now already not nesting interrupts but when i encountered that problem, it came interesting to me so i shared it with forum.
> > --
> > --
> > > Serial communication does not work in the isr, so that means serial
> > > interrupts do not work.
> > No. You only know that your print functions doesn't send data throught the serial port, not that the serial port doesn't work. It's rather the other way around: Your print uses interrupts, so your print doesn't work in the ISR which means no data can be sent in the ISR.
> > As printf function does not work in timer isr, RX and TX isr could not work either because; i used such function that communicates serially with the slave device. It was so obvious that;
> > msp430 could not communicate with slave device using serial interrupts while it is in the timer isr. I read in the manul that interrupt nesting is possible and i saw that serial interrupts didnt work in the timer isr. After that conflict between practice and the manual, that problem came interesting to me, my all stuff was that, i wanted to share with forum.
> > Anyway, i already have my solution now and my system works correctly. I agree with you too that in isr long works must be avoided and only software flags maybe set to effect the program flow of the main routine.
> >
> >
> >
> > --- In m...@yahoogroups.com, "Hayashi, Steve" wrote:
> > >
> > > Wait a minute, how does serial communication NOT work during an ISR? I don't think you understand ISRs correctly, or perhaps I just don't understand you.
> > >
> > > Step 1: Store all the data you intend to transmit into a global array. Save the size of the data in the array as a global variable. Set up a global pointer to the beginning of this array.
> > > Step 2: Set up a USCI Tx ISR. Have it send the byte of that the pointer is pointing to. Increment the pointer. And decrement the size of the data variable left in the array. If that variable is zero, just put the pointer back to the beginning of the array.
> > > Step 3: In your Timer ISR, have it do the same thing as your USCI Tx ISR.
> > >
> > > The USCI Tx ISR gets called every time serial (or SPI, or even I2C) gets transmitted. It is a very code efficient way of transmitting an array of data. Your timer just starts things by sending out the first byte.
> > >
> > > This is guaranteed to work unless your Timer gets called more frequently than it takes the processor to transmit that amount of data. If that's the case, clear the Timer interrupt enable in the USCI Tx ISR, but be sure to set it again when you've transmitted your last byte.
> > >
> > > -Steve
> > >
> > > ________________________________
> > > From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of erdemdilmen@
> > > Sent: Friday, August 28, 2009 4:02 AM
> > > To: m...@yahoogroups.com
> > > Subject: [msp430] Re: Interrupt nesting - msp430f248
> > >
> > >
> > >
> > >
> > > Hi,
> > > >I am trying to run a function which uses serial port communication, so serial interrupts, in the timer interrupt service routine. Although the same function works correctly in the main function, it does not do so in the timer isr. I tried to set global interrupt bit(GIE) whether that bit may be reset or not but; after that, the device resets itself. That seemed to not to be solution. What may the sloution be?
> > > >------------------------------------
> > > >
> > > >Hi,
> > > I read the manual of msp430f248 and i know correctly how interrupts work. If i didnt understand it how can i use serial interrupts or timer interrupts which work correctly? Here the non-understood thing is my question. I can already use serial interrupts, e.g. making serial comminucation and printing something on console. In the main code, all initializations are amde for UART and timer modules and also their interrupts are enabled so that; the PC can access the isr of timer module and i can print something while PC is still in the main code. But why can not it print something while it is the isr of timer? I read the manuals and i didnt see anything related to that. Such a problem is an undefined one so; there is not a solution defined that can encounter it. Serial communication does not work in the isr, so that means serial interrupts do not work. I read in the manual that msp430 let interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(comes nonsense to me) while accessing to the isr In fact; i do not preffer making long work like serial communication in the timer isr but the reason for that is as follows. I want msp430 to make serial communication with a slave device and print the data received from it at each 5 seconds. I will do that by timer interrupt. But in that 5 seconds, i want it to be LPM_3 and wake up only for serial communication. I thought maybe it can sleep 5 seconds and in the isr it can make its serial communication. It has nothing else to do in the main code or in other some isr so i thought it wont be a problem to make a long work in the isr of timer. But it seems that strategy doesnt work and i will change it.
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,
Task queue may be a better solution rather than using software flags.
>From now, i wont use printf() in isr.
tintronic wrote:
"It just so happens that on Wednesday, for the first time ever, I needed to enable nested interrupts. While I was enabling GIE within TimerB_ISR, a question interrupted my train of tought:
> In the TimerA_ISR, did you disable the TimerA IE or cleared IFG before setting GIE? Otherwise the TimerA_ISR would have been called again right after enabling GIE. This means you would have had an infinite nesting of TimerA_ISR untill your stack overflowed and started messing up your entire RAM content (and maybe some SFR too). This would explain why you could never print (TimerA_ISR would never have arrived to the print instruction)."
After entering the isr i did not clear the timer_A IE or IFG because as it is written in the pdf, slau144e.pdf, on page 407, there writes "The TACCR0 CCIFG flag has the highest Timer_A interrupt priority and has a dedicated interrupt vector as shown in Figure 12−15. The TACCR0 CCIFG flag is automatically reset when the TACCR0 interrupt request is serviced.", there was no need to clear. Here the interesting thing was, when i set the bit GIE it resets itself and the reason may be as you said, stack overflow, i agree with you at that point but; when i did not set the bit GIE in the isr, printf() did not work again although the device did not reset itself.
I wont use interrupt nesting if it is not so necessary. Thanks for your solution suggestions.

Best Regards,
Erdem.

--- In m...@yahoogroups.com, "tintronic" wrote:
>
> It just so happens that on Wednesday, for the first time ever, I needed to enable nested interrupts. While I was enabling GIE within TimerB_ISR, a question interrupted my train of tought:
> In the TimerA_ISR, did you disable the TimerA IE or cleared IFG before setting GIE? Otherwise the TimerA_ISR would have been called again right after enabling GIE. This means you would have had an infinite nesting of TimerA_ISR untill your stack overflowed and started messing up your entire RAM content (and maybe some SFR too). This would explain why you could never print (TimerA_ISR would never have arrived to the print instruction).
>
> My problem was that TimerA_ISR had to had a higher priority than TimerB_ISR, but ISR priorities are hardwired into the MSP430. The problem occurred that when 3 TimerB interrupts coincided, one of the much higher frequency TimerA interrupts was missed. TimerB_ISR is already stripped to the minimum.
>
> So I only had to add 4 lines to my TimerB_ISR (and create two 4-line enable/disable functions). These were:
>
> __interrupt void TimerB_ISR (void)
> {
> Disable_TB_ints(); // Added this to avoid TimerB_ISR self-nesting
> _EINT(); // Enable GIE
> ...
> switch (TBIV)
> (servicing of the interrupt)
> ...
> _DINT(); // Disable GIE (back to normal) to avoid self-nesting
> Enable_TB_ints(); // Re-enable TimerB interrupts
> }
>
> I solved my TimerA_ISR attending problem and didn't have any additional problem (other than foregetting to put the _DINT() instruction). I increased the stack size just in case, since I effectively created an additional nesting layer (now timerB ISR will sometimes be pushed onto the stack).
>
> Out of pure academic excercise, you might want to check this in your old ISR and see if now your print function works.
>
> > > Well, i can say -i can also real my car and drive it around my
> > > block without accident- because; i have already drived it before
> > > and it was successfull, that is the reason for me to be sure about
> > > my Rx and Tx interrupts work correctly.
>
> My point was not on your Rx and Tx routines, but in your statement:
>
> > > I read the manual of msp430f248 and i know correctly how
> > > interrupts work. If i didnt understand it how can i use serial
> > > interrupts or timer interrupts which work correctly?
> > > As printf function does not work in timer isr, RX and TX isr could
> > > not work either because; i used such function that communicates
> > > serially with the slave device. It was so obvious that;
> > > msp430 could not communicate with slave device using serial
> > > interrupts while it is in the timer isr.
> You didn't write that in your post, you wrote:
> > Serial communication does not work in the isr, so that means serial
> > interrupts do not work.
> My point is that serial communication does work on the hardware level, and that your problem was the print function which uses the serial port, not the serial port itself.
>
> Hope my case helps you with your original nesting problem.
>
> Regards,
> Michael K.
>
> --- In m...@yahoogroups.com, "jedi_erdi" wrote:
> >
> > Hi to all,
> > I changed my strategy and now i am not doing the work in the timer isr but; doing it in the main routine. I used software flags which are used as the states of the program flow in the main routine. My problem has been solved. Thanks for all solution suggestions but some misunderstandings happened.
> > Tintronic wrote:
> > "> I read the manual of msp430f248 and i know correctly how interrupts
> > > work. If i didnt understand it how can i use serial interrupts or
> > > timer interrupts which work correctly?
> > You can also real your cars manual and drive around your block without causing an accident. That doesn't mean you know how to drive. (Your block may not have any semaphores)"
> > Before strating to work on timer module i have already used serial communication which uses Rx and Tx interrupts successfully so that means; my serial interrupts are correct.
> > Well, i can say -i can also real my car and drive it around my block without accident- because; i have already drived it before and it was successfull, that is the reason for me to be sure about my Rx and Tx interrupts work correctly.
> > --
> > --
> > > I thought, maybe the GIE bit is reset(comes nonsense to me) while
> > > accessing to the isr of timer so; serial interrupts are disabled.
> > It's NOT nonsense. I don't know a microcontroller that doesn't disable GIE when the PC jumps to an interrupt vector (when triggered by the interrupt of course).
> > Take another look at the MSP430x2xx user's guide under 2.2.3 "Interrupt Processing". I quote step 6 of the interrupt logic flow:
> > "6) The SR is cleared. This terminates any low-power mode. Because the GIE bit is cleared, further interrupts are disabled."
> > I read the manual,slau144e.pdf, and on the page 33 of it there writes:
> > "Interrupt nesting is enabled if the GIE bit is set inside an interrupt service routine. When interrupt nesting is enabled, any interrupt occurring during an interrupt service routine will interrupt the routine, regardless of the interrupt priorities."
> > So it is obvious that interrupt nesting is possible. It came nonse to me that GIE bit will be reset because i have never read such a thimg on that manual. I tried to again set the GIE bit in the timer ISR but;
> > serial interrupts didnt work. After that, i thought, "although it is written in the manual that; interrupt nesting is possible why can not i nest interrupts??" Maybe that is not so important because
> > i am now already not nesting interrupts but when i encountered that problem, it came interesting to me so i shared it with forum.
> > --
> > --
> > > Serial communication does not work in the isr, so that means serial
> > > interrupts do not work.
> > No. You only know that your print functions doesn't send data throught the serial port, not that the serial port doesn't work. It's rather the other way around: Your print uses interrupts, so your print doesn't work in the ISR which means no data can be sent in the ISR.
> > As printf function does not work in timer isr, RX and TX isr could not work either because; i used such function that communicates serially with the slave device. It was so obvious that;
> > msp430 could not communicate with slave device using serial interrupts while it is in the timer isr. I read in the manul that interrupt nesting is possible and i saw that serial interrupts didnt work in the timer isr. After that conflict between practice and the manual, that problem came interesting to me, my all stuff was that, i wanted to share with forum.
> > Anyway, i already have my solution now and my system works correctly. I agree with you too that in isr long works must be avoided and only software flags maybe set to effect the program flow of the main routine.
> >
> >
> >
> > --- In m...@yahoogroups.com, "Hayashi, Steve" wrote:
> > >
> > > Wait a minute, how does serial communication NOT work during an ISR? I don't think you understand ISRs correctly, or perhaps I just don't understand you.
> > >
> > > Step 1: Store all the data you intend to transmit into a global array. Save the size of the data in the array as a global variable. Set up a global pointer to the beginning of this array.
> > > Step 2: Set up a USCI Tx ISR. Have it send the byte of that the pointer is pointing to. Increment the pointer. And decrement the size of the data variable left in the array. If that variable is zero, just put the pointer back to the beginning of the array.
> > > Step 3: In your Timer ISR, have it do the same thing as your USCI Tx ISR.
> > >
> > > The USCI Tx ISR gets called every time serial (or SPI, or even I2C) gets transmitted. It is a very code efficient way of transmitting an array of data. Your timer just starts things by sending out the first byte.
> > >
> > > This is guaranteed to work unless your Timer gets called more frequently than it takes the processor to transmit that amount of data. If that's the case, clear the Timer interrupt enable in the USCI Tx ISR, but be sure to set it again when you've transmitted your last byte.
> > >
> > > -Steve
> > >
> > > ________________________________
> > > From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of erdemdilmen@
> > > Sent: Friday, August 28, 2009 4:02 AM
> > > To: m...@yahoogroups.com
> > > Subject: [msp430] Re: Interrupt nesting - msp430f248
> > >
> > >
> > >
> > >
> > > Hi,
> > > >I am trying to run a function which uses serial port communication, so serial interrupts, in the timer interrupt service routine. Although the same function works correctly in the main function, it does not do so in the timer isr. I tried to set global interrupt bit(GIE) whether that bit may be reset or not but; after that, the device resets itself. That seemed to not to be solution. What may the sloution be?
> > > >------------------------------------
> > > >
> > > >Hi,
> > > I read the manual of msp430f248 and i know correctly how interrupts work. If i didnt understand it how can i use serial interrupts or timer interrupts which work correctly? Here the non-understood thing is my question. I can already use serial interrupts, e.g. making serial comminucation and printing something on console. In the main code, all initializations are amde for UART and timer modules and also their interrupts are enabled so that; the PC can access the isr of timer module and i can print something while PC is still in the main code. But why can not it print something while it is the isr of timer? I read the manuals and i didnt see anything related to that. Such a problem is an undefined one so; there is not a solution defined that can encounter it. Serial communication does not work in the isr, so that means serial interrupts do not work. I read in the manual that msp430 let interrupt nesting if GIE bit is set. I thought, maybe the GIE bit is reset(comes nonsense to me) while accessing to the isr In fact; i do not preffer making long work like serial communication in the timer isr but the reason for that is as follows. I want msp430 to make serial communication with a slave device and print the data received from it at each 5 seconds. I will do that by timer interrupt. But in that 5 seconds, i want it to be LPM_3 and wake up only for serial communication. I thought maybe it can sleep 5 seconds and in the isr it can make its serial communication. It has nothing else to do in the main code or in other some isr so i thought it wont be a problem to make a long work in the isr of timer. But it seems that strategy doesnt work and i will change it.
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )