EmbeddedRelated.com
Forums

MSP430F168 and UART RX interrupt handling issues when not using LPM

Started by mtxelectronics July 23, 2009
Hi, I am having a little issue with using the interrupt service routine to read a byte from UART1 of the MSP430F168 MCU.I am trying to create a buffer of all data received through UART1 but what is happening is that after I regularly service the interrupt this will continuously repeat itself even if I don't send any data to the UART.

In the MSP430x1xx user's guide on page 13-18 I read:
"USART Receive Interrupt Operation
The URXIFGx interrupt flag is set each time a character is received and loaded into UxRXBUF. An interrupt request is generated if URXIEx and GIE are also set. URXIFGx and URXIEx are reset by a system reset PUC signal or when SWRST = 1. URXIFGx is automatically reset if the pending interrupt is served (when URXSE = 0) or when UxRXBUF is read. The operation is shown in Figure 13−11."

Therefor I would suppose that by entering the interrupt service routine & reading the U1RXBUF I should have reset all flags and a new interrupt should only occur if I actually receive new data on the UART but this is not the case...

This is my current interrupt service routine:
void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
{
// Put byte in buffer
if (gBytesReadLength < MAX_UART_PACKET_SIZE)
BytesRead[gBytesReadLength++]=RXBUF1;

gTimeElapsed=0;
}

I have also tried to manually reset URXIFG1 (IFG2 &= ~URXIFG1) at the end of the routine but the behavior does not change.

The only way I have been able to "patch" the problem is by using the following code:
void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
{
if (IFG2 & URXIFG1) // Only execute if a byte has been really received
{
// Put byte in buffer
if (gBytesReadLength < MAX_UART_PACKET_SIZE)
gBytesRead[gBytesReadLength++]=RXBUF1;

gTimeElapsed=0;
}
}

The problem is that I do not like this code because the interrupt is serviced continuasly wasting valuable system resources and blocking the CPu from doing other things.

As I said in the subject I am not using any LPM modes, this is because I do not any power issue with this project and other functions are continuasly executing other routines constantly.

Beginning Microcontrollers with the MSP430

I can see right away a potential problem in your SerialInterrupt1():
> This is my current interrupt service routine:
> void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> {
> // Put byte in buffer
> if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> BytesRead[gBytesReadLength++]=RXBUF1;
>
> gTimeElapsed=0;
> }

what happens if gBytesReadLength is greater or equeal to MAX_UART_PACKET_SIZE? RXBUF1 is not read (I suppose that is URXBUF1), so the interrupt is not cleared and the MSP will stay in a loop in this routine forever, unless another interrupt with higher priority changes the value of one of the variables in the if() statement (or clears the IFG or reads RXBUF1), or you do it manually throught the debugger interface.

Your second attempt does nothing to solve this issue.

Regards,
Michael K.

--- In m..., "mtxelectronics" wrote:
>
> Hi, I am having a little issue with using the interrupt service routine to read a byte from UART1 of the MSP430F168 MCU.I am trying to create a buffer of all data received through UART1 but what is happening is that after I regularly service the interrupt this will continuously repeat itself even if I don't send any data to the UART.
>
> In the MSP430x1xx user's guide on page 13-18 I read:
> "USART Receive Interrupt Operation
> The URXIFGx interrupt flag is set each time a character is received and loaded into UxRXBUF. An interrupt request is generated if URXIEx and GIE are also set. URXIFGx and URXIEx are reset by a system reset PUC signal or when SWRST = 1. URXIFGx is automatically reset if the pending interrupt is served (when URXSE = 0) or when UxRXBUF is read. The operation is shown in Figure 13−11."
>
> Therefor I would suppose that by entering the interrupt service routine & reading the U1RXBUF I should have reset all flags and a new interrupt should only occur if I actually receive new data on the UART but this is not the case...
>
> This is my current interrupt service routine:
> void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> {
> // Put byte in buffer
> if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> BytesRead[gBytesReadLength++]=RXBUF1;
>
> gTimeElapsed=0;
> }
>
> I have also tried to manually reset URXIFG1 (IFG2 &= ~URXIFG1) at the end of the routine but the behavior does not change.
>
> The only way I have been able to "patch" the problem is by using the following code:
> void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> {
> if (IFG2 & URXIFG1) // Only execute if a byte has been really received
> {
> // Put byte in buffer
> if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> gBytesRead[gBytesReadLength++]=RXBUF1;
>
> gTimeElapsed=0;
> }
> }
>
> The problem is that I do not like this code because the interrupt is serviced continuasly wasting valuable system resources and blocking the CPu from doing other things.
>
> As I said in the subject I am not using any LPM modes, this is because I do not any power issue with this project and other functions are continuasly executing other routines constantly.
>

Yes, you are right. I had already noticed that issue but have not done
anything about it because I am currently testing with a terminale editor
and only type one or two char's for testes. The MAX_UART_PACKET_SIZE
constant is currently set to 32.

Currently I will start the software and all seems well (no interrupt's
are called) but when I type a character on the terminal the interrupt
will catch the event and BytesRead[] array will acquire the value and
increment gBytesReadLength. The problem as I said before is that after
finishing the interrupt request it will basically just loop forever
servicing the same interrupt and therefor incrementing the array with
the last character received. If I type another character the UART will
acquire the new data and continue it's endless loop with this new
character. I odviusly stop this before reaching the MAX_UART_PACKET_SIZE :)

Ohh, yes. RXBUF1 is a define for URXBUF1.

Regards,
Salvo

tintronic wrote:
>
>
> I can see right away a potential problem in your SerialInterrupt1():
> > This is my current interrupt service routine:
> > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > {
> > // Put byte in buffer
> > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > BytesRead[gBytesReadLength++]=RXBUF1;
> >
> > gTimeElapsed=0;
> > }
>
> what happens if gBytesReadLength is greater or equeal to
> MAX_UART_PACKET_SIZE? RXBUF1 is not read (I suppose that is URXBUF1),
> so the interrupt is not cleared and the MSP will stay in a loop in
> this routine forever, unless another interrupt with higher priority
> changes the value of one of the variables in the if() statement (or
> clears the IFG or reads RXBUF1), or you do it manually throught the
> debugger interface.
>
> Your second attempt does nothing to solve this issue.
>
> Regards,
> Michael K.
>
> --- In m... ,
> "mtxelectronics" wrote:
> >
> > Hi, I am having a little issue with using the interrupt service
> routine to read a byte from UART1 of the MSP430F168 MCU.I am trying to
> create a buffer of all data received through UART1 but what is
> happening is that after I regularly service the interrupt this will
> continuously repeat itself even if I don't send any data to the UART.
> >
> > In the MSP430x1xx user's guide on page 13-18 I read:
> > "USART Receive Interrupt Operation
> > The URXIFGx interrupt flag is set each time a character is received
> and loaded into UxRXBUF. An interrupt request is generated if URXIEx
> and GIE are also set. URXIFGx and URXIEx are reset by a system reset
> PUC signal or when SWRST = 1. URXIFGx is automatically reset if the
> pending interrupt is served (when URXSE = 0) or when UxRXBUF is read.
> The operation is shown in Figure 13−11."
> >
> > Therefor I would suppose that by entering the interrupt service
> routine & reading the U1RXBUF I should have reset all flags and a new
> interrupt should only occur if I actually receive new data on the UART
> but this is not the case...
> >
> > This is my current interrupt service routine:
> > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > {
> > // Put byte in buffer
> > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > BytesRead[gBytesReadLength++]=RXBUF1;
> >
> > gTimeElapsed=0;
> > }
> >
> > I have also tried to manually reset URXIFG1 (IFG2 &= ~URXIFG1) at
> the end of the routine but the behavior does not change.
> >
> > The only way I have been able to "patch" the problem is by using the
> following code:
> > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > {
> > if (IFG2 & URXIFG1) // Only execute if a byte has been really received
> > {
> > // Put byte in buffer
> > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > gBytesRead[gBytesReadLength++]=RXBUF1;
> >
> > gTimeElapsed=0;
> > }
> > }
> >
> > The problem is that I do not like this code because the interrupt is
> serviced continuasly wasting valuable system resources and blocking
> the CPu from doing other things.
> >
> > As I said in the subject I am not using any LPM modes, this is
> because I do not any power issue with this project and other functions
> are continuasly executing other routines constantly.
> >

--
Salvatore Faro
Tel/Fax: +39 095391616
Cell: +39 3894735999

MTX Electronics
Via Pietro Paolo Vasta, 8
95045 Misterbianco (CT)
Italia

Internet: www.mtx-electronics.com
Email: f...@mtx-electronics.com

------
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above and main contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message.

Are you sure your serial console PC program isn't constantly sending data? It seams the only explanation. Test that: shortcircuit DB9 pins 2 and 3 of the PC and see what happens when you type in a letter.

Alternatively, see in your debugger options if it stops some clock sources when you stop the MSP. If it stops the UART1 clock source then there is no way the MSP can receive characters while stopped.

Anyway, don't leave anything to chance. You shouldn't assume gBytesReadLength will never reach MAX_UART_PACKET_SIZE. Otherwise, why even bother with the if() statement? You're just changing the eventual bug from one source to another. Try this:
void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
{
BytesRead[gBytesReadLength] = RXBUF1;
if (gBytesReadLength < MAX_UART_PACKET_SIZE)
gBytesReadLength++;
gTimeElapsed=0;
}

Regards,
Michael K.

--- In m..., Salvatore Faro wrote:
>
> Yes, you are right. I had already noticed that issue but have not done
> anything about it because I am currently testing with a terminale editor
> and only type one or two char's for testes. The MAX_UART_PACKET_SIZE
> constant is currently set to 32.
>
> Currently I will start the software and all seems well (no interrupt's
> are called) but when I type a character on the terminal the interrupt
> will catch the event and BytesRead[] array will acquire the value and
> increment gBytesReadLength. The problem as I said before is that after
> finishing the interrupt request it will basically just loop forever
> servicing the same interrupt and therefor incrementing the array with
> the last character received. If I type another character the UART will
> acquire the new data and continue it's endless loop with this new
> character. I odviusly stop this before reaching the MAX_UART_PACKET_SIZE :)
>
> Ohh, yes. RXBUF1 is a define for URXBUF1.
>
> Regards,
> Salvo
>
> tintronic wrote:
> >
> >
> > I can see right away a potential problem in your SerialInterrupt1():
> > > This is my current interrupt service routine:
> > > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > > {
> > > // Put byte in buffer
> > > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > > BytesRead[gBytesReadLength++]=RXBUF1;
> > >
> > > gTimeElapsed=0;
> > > }
> >
> > what happens if gBytesReadLength is greater or equeal to
> > MAX_UART_PACKET_SIZE? RXBUF1 is not read (I suppose that is URXBUF1),
> > so the interrupt is not cleared and the MSP will stay in a loop in
> > this routine forever, unless another interrupt with higher priority
> > changes the value of one of the variables in the if() statement (or
> > clears the IFG or reads RXBUF1), or you do it manually throught the
> > debugger interface.
> >
> > Your second attempt does nothing to solve this issue.
> >
> > Regards,
> > Michael K.
> >
> > --- In m... ,
> > "mtxelectronics" wrote:
> > >
> > > Hi, I am having a little issue with using the interrupt service
> > routine to read a byte from UART1 of the MSP430F168 MCU.I am trying to
> > create a buffer of all data received through UART1 but what is
> > happening is that after I regularly service the interrupt this will
> > continuously repeat itself even if I don't send any data to the UART.
> > >
> > > In the MSP430x1xx user's guide on page 13-18 I read:
> > > "USART Receive Interrupt Operation
> > > The URXIFGx interrupt flag is set each time a character is received
> > and loaded into UxRXBUF. An interrupt request is generated if URXIEx
> > and GIE are also set. URXIFGx and URXIEx are reset by a system reset
> > PUC signal or when SWRST = 1. URXIFGx is automatically reset if the
> > pending interrupt is served (when URXSE = 0) or when UxRXBUF is read.
> > The operation is shown in Figure 13−11."
> > >
> > > Therefor I would suppose that by entering the interrupt service
> > routine & reading the U1RXBUF I should have reset all flags and a new
> > interrupt should only occur if I actually receive new data on the UART
> > but this is not the case...
> > >
> > > This is my current interrupt service routine:
> > > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > > {
> > > // Put byte in buffer
> > > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > > BytesRead[gBytesReadLength++]=RXBUF1;
> > >
> > > gTimeElapsed=0;
> > > }
> > >
> > > I have also tried to manually reset URXIFG1 (IFG2 &= ~URXIFG1) at
> > the end of the routine but the behavior does not change.
> > >
> > > The only way I have been able to "patch" the problem is by using the
> > following code:
> > > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > > {
> > > if (IFG2 & URXIFG1) // Only execute if a byte has been really received
> > > {
> > > // Put byte in buffer
> > > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > > gBytesRead[gBytesReadLength++]=RXBUF1;
> > >
> > > gTimeElapsed=0;
> > > }
> > > }
> > >
> > > The problem is that I do not like this code because the interrupt is
> > serviced continuasly wasting valuable system resources and blocking
> > the CPu from doing other things.
> > >
> > > As I said in the subject I am not using any LPM modes, this is
> > because I do not any power issue with this project and other functions
> > are continuasly executing other routines constantly.
> > >
> >
> > --
> Salvatore Faro
> Tel/Fax: +39 095391616
> Cell: +39 3894735999
>
> MTX Electronics
> Via Pietro Paolo Vasta, 8
> 95045 Misterbianco (CT)
> Italia
>
> Internet: www.mtx-electronics.com
> Email: faro@...
>
> ------
> CONFIDENTIALITY NOTICE
> This message and its attachments are addressed solely to the persons above and main contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message.
>

Thanks for the tip. Well I'm 100% sure that it is an MSP issue and not external. I've verified all possible external problems and nothing seems to be wrong. Like I mentioned if I send data from my terminal to the device it receives it perfectly, even entire strings of data (I have just for the sake tried with two different terminal progs. but as I thought nothing changed). It just seems that it continues to service interrupt without one really occuring...

I did notice that when the interrupt routine is executed the URXIFG1 flag is disabled as I would expect.

I have also tried removing the interrupt routine and disabling the uart1 rx interrupt flag. Then I made the software use a regular polling routine when I wanted to read data from the uart and the firmware is fully working. I'm reading & writing both to a MODBUS device & Allen Bradley PLC in DF1 protocol without issue of any kind.

If there was an issue with the hardware or connections I would expect to have problems but this is not the case... This is really puzzling!

P.S. I have two MSP boards and both behave in the same manner.

I'm sure that the problem has to be in something that I am doing wrong in the configuration and/or handling of the interrupt but I just don't get it.

--- In m..., "tintronic" wrote:
>
> Are you sure your serial console PC program isn't constantly sending data? It seams the only explanation. Test that: shortcircuit DB9 pins 2 and 3 of the PC and see what happens when you type in a letter.
>
> Alternatively, see in your debugger options if it stops some clock sources when you stop the MSP. If it stops the UART1 clock source then there is no way the MSP can receive characters while stopped.
>
> Anyway, don't leave anything to chance. You shouldn't assume gBytesReadLength will never reach MAX_UART_PACKET_SIZE. Otherwise, why even bother with the if() statement? You're just changing the eventual bug from one source to another. Try this:
> void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> {
> BytesRead[gBytesReadLength] = RXBUF1;
> if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> gBytesReadLength++;
> gTimeElapsed=0;
> }
>
> Regards,
> Michael K.
>
> --- In m..., Salvatore Faro wrote:
> >
> > Yes, you are right. I had already noticed that issue but have not done
> > anything about it because I am currently testing with a terminale editor
> > and only type one or two char's for testes. The MAX_UART_PACKET_SIZE
> > constant is currently set to 32.
> >
> > Currently I will start the software and all seems well (no interrupt's
> > are called) but when I type a character on the terminal the interrupt
> > will catch the event and BytesRead[] array will acquire the value and
> > increment gBytesReadLength. The problem as I said before is that after
> > finishing the interrupt request it will basically just loop forever
> > servicing the same interrupt and therefor incrementing the array with
> > the last character received. If I type another character the UART will
> > acquire the new data and continue it's endless loop with this new
> > character. I odviusly stop this before reaching the MAX_UART_PACKET_SIZE :)
> >
> > Ohh, yes. RXBUF1 is a define for URXBUF1.
> >
> > Regards,
> > Salvo
> >
> > tintronic wrote:
> > >
> > >
> > > I can see right away a potential problem in your SerialInterrupt1():
> > > > This is my current interrupt service routine:
> > > > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > > > {
> > > > // Put byte in buffer
> > > > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > > > BytesRead[gBytesReadLength++]=RXBUF1;
> > > >
> > > > gTimeElapsed=0;
> > > > }
> > >
> > > what happens if gBytesReadLength is greater or equeal to
> > > MAX_UART_PACKET_SIZE? RXBUF1 is not read (I suppose that is URXBUF1),
> > > so the interrupt is not cleared and the MSP will stay in a loop in
> > > this routine forever, unless another interrupt with higher priority
> > > changes the value of one of the variables in the if() statement (or
> > > clears the IFG or reads RXBUF1), or you do it manually throught the
> > > debugger interface.
> > >
> > > Your second attempt does nothing to solve this issue.
> > >
> > > Regards,
> > > Michael K.
> > >
> > > --- In m... ,
> > > "mtxelectronics" wrote:
> > > >
> > > > Hi, I am having a little issue with using the interrupt service
> > > routine to read a byte from UART1 of the MSP430F168 MCU.I am trying to
> > > create a buffer of all data received through UART1 but what is
> > > happening is that after I regularly service the interrupt this will
> > > continuously repeat itself even if I don't send any data to the UART.
> > > >
> > > > In the MSP430x1xx user's guide on page 13-18 I read:
> > > > "USART Receive Interrupt Operation
> > > > The URXIFGx interrupt flag is set each time a character is received
> > > and loaded into UxRXBUF. An interrupt request is generated if URXIEx
> > > and GIE are also set. URXIFGx and URXIEx are reset by a system reset
> > > PUC signal or when SWRST = 1. URXIFGx is automatically reset if the
> > > pending interrupt is served (when URXSE = 0) or when UxRXBUF is read.
> > > The operation is shown in Figure 13−11."
> > > >
> > > > Therefor I would suppose that by entering the interrupt service
> > > routine & reading the U1RXBUF I should have reset all flags and a new
> > > interrupt should only occur if I actually receive new data on the UART
> > > but this is not the case...
> > > >
> > > > This is my current interrupt service routine:
> > > > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > > > {
> > > > // Put byte in buffer
> > > > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > > > BytesRead[gBytesReadLength++]=RXBUF1;
> > > >
> > > > gTimeElapsed=0;
> > > > }
> > > >
> > > > I have also tried to manually reset URXIFG1 (IFG2 &= ~URXIFG1) at
> > > the end of the routine but the behavior does not change.
> > > >
> > > > The only way I have been able to "patch" the problem is by using the
> > > following code:
> > > > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > > > {
> > > > if (IFG2 & URXIFG1) // Only execute if a byte has been really received
> > > > {
> > > > // Put byte in buffer
> > > > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > > > gBytesRead[gBytesReadLength++]=RXBUF1;
> > > >
> > > > gTimeElapsed=0;
> > > > }
> > > > }
> > > >
> > > > The problem is that I do not like this code because the interrupt is
> > > serviced continuasly wasting valuable system resources and blocking
> > > the CPu from doing other things.
> > > >
> > > > As I said in the subject I am not using any LPM modes, this is
> > > because I do not any power issue with this project and other functions
> > > are continuasly executing other routines constantly.
> > > >
> > >
> > >
> >
> > --
> > Salvatore Faro
> > Tel/Fax: +39 095391616
> > Cell: +39 3894735999
> >
> > MTX Electronics
> > Via Pietro Paolo Vasta, 8
> > 95045 Misterbianco (CT)
> > Italia
> >
> > Internet: www.mtx-electronics.com
> > Email: faro@
> >
> > ------
> > CONFIDENTIALITY NOTICE
> > This message and its attachments are addressed solely to the persons above and main contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message.
>

Then it sounds like an interrupt that is enabled but for which there is no service routine, so the program counter keeps going untill it reaches the RX interrupt vector and jumps to that ISR (TX interrupt enabled?). I'm not sure if this happens on the MSP430, but I do know it happens on the PIC16. Check for that.

Regards,
Michael K.

--- In m..., "mtxelectronics" wrote:
>
> Thanks for the tip. Well I'm 100% sure that it is an MSP issue and not external. I've verified all possible external problems and nothing seems to be wrong. Like I mentioned if I send data from my terminal to the device it receives it perfectly, even entire strings of data (I have just for the sake tried with two different terminal progs. but as I thought nothing changed). It just seems that it continues to service interrupt without one really occuring...
>
> I did notice that when the interrupt routine is executed the URXIFG1 flag is disabled as I would expect.
>
> I have also tried removing the interrupt routine and disabling the uart1 rx interrupt flag. Then I made the software use a regular polling routine when I wanted to read data from the uart and the firmware is fully working. I'm reading & writing both to a MODBUS device & Allen Bradley PLC in DF1 protocol without issue of any kind.
>
> If there was an issue with the hardware or connections I would expect to have problems but this is not the case... This is really puzzling!
>
> P.S. I have two MSP boards and both behave in the same manner.
>
> I'm sure that the problem has to be in something that I am doing wrong in the configuration and/or handling of the interrupt but I just don't get it.
>
> --- In m..., "tintronic" wrote:
> >
> > Are you sure your serial console PC program isn't constantly sending data? It seams the only explanation. Test that: shortcircuit DB9 pins 2 and 3 of the PC and see what happens when you type in a letter.
> >
> > Alternatively, see in your debugger options if it stops some clock sources when you stop the MSP. If it stops the UART1 clock source then there is no way the MSP can receive characters while stopped.
> >
> > Anyway, don't leave anything to chance. You shouldn't assume gBytesReadLength will never reach MAX_UART_PACKET_SIZE. Otherwise, why even bother with the if() statement? You're just changing the eventual bug from one source to another. Try this:
> > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > {
> > BytesRead[gBytesReadLength] = RXBUF1;
> > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > gBytesReadLength++;
> > gTimeElapsed=0;
> > }
> >
> > Regards,
> > Michael K.
> >
> > --- In m..., Salvatore Faro wrote:
> > >
> > > Yes, you are right. I had already noticed that issue but have not done
> > > anything about it because I am currently testing with a terminale editor
> > > and only type one or two char's for testes. The MAX_UART_PACKET_SIZE
> > > constant is currently set to 32.
> > >
> > > Currently I will start the software and all seems well (no interrupt's
> > > are called) but when I type a character on the terminal the interrupt
> > > will catch the event and BytesRead[] array will acquire the value and
> > > increment gBytesReadLength. The problem as I said before is that after
> > > finishing the interrupt request it will basically just loop forever
> > > servicing the same interrupt and therefor incrementing the array with
> > > the last character received. If I type another character the UART will
> > > acquire the new data and continue it's endless loop with this new
> > > character. I odviusly stop this before reaching the MAX_UART_PACKET_SIZE :)
> > >
> > > Ohh, yes. RXBUF1 is a define for URXBUF1.
> > >
> > > Regards,
> > > Salvo
> > >
> > > tintronic wrote:
> > > >
> > > >
> > > > I can see right away a potential problem in your SerialInterrupt1():
> > > > > This is my current interrupt service routine:
> > > > > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > > > > {
> > > > > // Put byte in buffer
> > > > > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > > > > BytesRead[gBytesReadLength++]=RXBUF1;
> > > > >
> > > > > gTimeElapsed=0;
> > > > > }
> > > >
> > > > what happens if gBytesReadLength is greater or equeal to
> > > > MAX_UART_PACKET_SIZE? RXBUF1 is not read (I suppose that is URXBUF1),
> > > > so the interrupt is not cleared and the MSP will stay in a loop in
> > > > this routine forever, unless another interrupt with higher priority
> > > > changes the value of one of the variables in the if() statement (or
> > > > clears the IFG or reads RXBUF1), or you do it manually throught the
> > > > debugger interface.
> > > >
> > > > Your second attempt does nothing to solve this issue.
> > > >
> > > > Regards,
> > > > Michael K.
> > > >
> > > > --- In m... ,
> > > > "mtxelectronics" wrote:
> > > > >
> > > > > Hi, I am having a little issue with using the interrupt service
> > > > routine to read a byte from UART1 of the MSP430F168 MCU.I am trying to
> > > > create a buffer of all data received through UART1 but what is
> > > > happening is that after I regularly service the interrupt this will
> > > > continuously repeat itself even if I don't send any data to the UART.
> > > > >
> > > > > In the MSP430x1xx user's guide on page 13-18 I read:
> > > > > "USART Receive Interrupt Operation
> > > > > The URXIFGx interrupt flag is set each time a character is received
> > > > and loaded into UxRXBUF. An interrupt request is generated if URXIEx
> > > > and GIE are also set. URXIFGx and URXIEx are reset by a system reset
> > > > PUC signal or when SWRST = 1. URXIFGx is automatically reset if the
> > > > pending interrupt is served (when URXSE = 0) or when UxRXBUF is read.
> > > > The operation is shown in Figure 13−11."
> > > > >
> > > > > Therefor I would suppose that by entering the interrupt service
> > > > routine & reading the U1RXBUF I should have reset all flags and a new
> > > > interrupt should only occur if I actually receive new data on the UART
> > > > but this is not the case...
> > > > >
> > > > > This is my current interrupt service routine:
> > > > > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > > > > {
> > > > > // Put byte in buffer
> > > > > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > > > > BytesRead[gBytesReadLength++]=RXBUF1;
> > > > >
> > > > > gTimeElapsed=0;
> > > > > }
> > > > >
> > > > > I have also tried to manually reset URXIFG1 (IFG2 &= ~URXIFG1) at
> > > > the end of the routine but the behavior does not change.
> > > > >
> > > > > The only way I have been able to "patch" the problem is by using the
> > > > following code:
> > > > > void SerialInterrupt1(void) __interrupt[UART1RX_VECTOR]
> > > > > {
> > > > > if (IFG2 & URXIFG1) // Only execute if a byte has been really received
> > > > > {
> > > > > // Put byte in buffer
> > > > > if (gBytesReadLength < MAX_UART_PACKET_SIZE)
> > > > > gBytesRead[gBytesReadLength++]=RXBUF1;
> > > > >
> > > > > gTimeElapsed=0;
> > > > > }
> > > > > }
> > > > >
> > > > > The problem is that I do not like this code because the interrupt is
> > > > serviced continuasly wasting valuable system resources and blocking
> > > > the CPu from doing other things.
> > > > >
> > > > > As I said in the subject I am not using any LPM modes, this is
> > > > because I do not any power issue with this project and other functions
> > > > are continuasly executing other routines constantly.
> > > > >
> > > >
> > > >
> > >
> > > --
> > > Salvatore Faro
> > > Tel/Fax: +39 095391616
> > > Cell: +39 3894735999
> > >
> > > MTX Electronics
> > > Via Pietro Paolo Vasta, 8
> > > 95045 Misterbianco (CT)
> > > Italia
> > >
> > > Internet: www.mtx-electronics.com
> > > Email: faro@
> > >
> > > ------
> > > CONFIDENTIALITY NOTICE
> > > This message and its attachments are addressed solely to the persons above and main contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message.
> > >
>