MC9S08GB60 multiple interrupts handling

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MC9S08GB60 multiple interrupts handling

1,998 Views
soethetsan
Contributor I
Hi,
 
I have a problem handling multiple interrupts.
 
Apparently, with MC9S08GB60 8-bit controller, I am trying to configure SCI2 communication using C in Freescale CodeWarrior. The application itself is upon receiving a particular string (e.g. !0000#), the receiving unit is to identify the string(!0000#) coming in and transmitting out acknowledgement (e.g. RecvOk). I have enabled both Transmit Interrupt (TIE) and Receiver Interrupt (RIE) to perform the task.
 
However, the problem here is when I enable both interrupts (i.e.,before "EnableInterrupts;" ), the main loop [for(;; )] is never executed at all [I put some LED indications(toggling) within for(;; ) loop to visibly see the execution].
 
I am sure I have cleared the SCI interrupt flags according to what is mentioned in the application notes by reading SCI2S1 register and write to SCI2D register for Tx IRQ. 
 
What I suspect here is that one of the interrupts is never going out from itself which results in not giving a chance to the main program. But I am not sure what is preventing the main program from running.
 
Hope somebody will help me with this.
 
With Regards,
Lydia
Labels (1)
0 Kudos
Reply
5 Replies

686 Views
soethetsan
Contributor I
Hi,
 
Thanks for helping me out. Actually my program is somehow up and running now but with a few limitations. (Pls take a careful look at //********** part).
 
My baud rate setting is 9600. For both interrupts, they do not run at the same time since flags are set to fire TxIRQ only after RxIRQ is done.
 
To Ake, pls take a look at my IRQ handlers. SCI2S1 is read and I suppose flags are properly cleared. I do not understand what you mean by the routine should not take more than 10%of the time. I believe the interrupts will shoot according to the baud rate which means 0.104 ms per character(9600b/s) and evertime each character is sent out or received, the interrupt will occur. Do correct me if my perception is wrong.
 
Here are my IRQ handlers. They are declared above main().
 
//---IRQ handlers---------------------------------------------------------

interrupt VSCI2RX void SCI2RXIRQ(){                  //having declared VSCI2RX=20 
  ucSCI2S1_RxReadChar=SCI2S1;                     //clearing flag according to application note
  ucRecvChar=SCI2D;                                    
 
  if((gucRxStrRdyFlg==RX_START)||(gucRxStrRdyFlg==RX_PROCESSING)){ //flags are set in main
    SCI2Rx_getMAC(ucRecvChar);                      //receiving data (e.g. !1000#), this function is declared
  }
}
 
interrupt VSCI2TX void SCI2TXIRQ(){              //having declared VSCI2TX=21
  ucSCI2S1_TxReadChar=SCI2S1;
 
  if((gucTxStrFlag==TX_START)||(gucTxStrFlag==TX_PROCESSING)){
    SCI2Tx_sendPHY(&gaucTxChar[0]);  //intend to transmit data (e.g. !001000#) upon receiving
  }else{                               //**********
    SCI2C2_SBK=1;
    SCI2C2_SBK=0;
  }
}
//-------------------------------------------------------------------------------------------
 
In main(), I have enabled both TCIE and RIE. Here what I add in is
SCI2C2_SBK=1; 
SCI2C2_SBK=0; so that I won't have the problem at all. The program works fine only if I add in this. If I do not queue a break character, the main program never gets a chance to execute at all. To be able to queue a break character, I need to use TCIE instead of TIE.
 
Here what I do not understand is why I cannot use TIE? The function to transmit data {which is SCI2Tx_sendPHY(&gaucTxChar[0]);} will only be executed according to the gucTxStrFlag settings (which I believe I have set them correctly in main()). If the right flags are not set, it won't transmit any data and shouldn't the whole program be alright? Well, if TIE is used instead of TCIE, the same problem of the main being not executed continue.
 
Do show me if you have any better solution than that.
 
And one more doubt. Is that possible to receive while at the same time transmitting? According to the vector no, RxIRQ has a higher vector priority than TxIRQ. Does that mean if I keep receiving, TxIRQ will never execute at all?     
 
With Regards,
Lydia          
 

 
 
0 Kudos
Reply

686 Views
peg
Senior Contributor IV
Hello Lydia,

It seems you have not taken heed of Tony's 2nd guess (my money was on this one).

Interrupts caused by TIE being set will fire every byte shift time (if you keep the shifter fed) or continuously (if you don't). This being the case if you have nothing ready to send you must disable this interrupt until you do.

What you have done to "fix" it is keep feeding the shifter with breaks when you have nothing to send. This then gives your main programme some time to execute. This is HIGHLY inefficient!

P.S. The same basically applies to interrupts caused by TCIE being set.


Message Edited by peg on 2008-12-05 02:09 PM
0 Kudos
Reply

686 Views
Ake
Contributor II
Hi,
It sounds to me like you are either
- not resetting the interrupt flag in the interrupt routine, which causes the interrupt to interrupt again as soon as it returns.
Add the following at the begining of the Rx and Tx interrupts.
This will clear the flag when reading/writing the SCI1D register.
 
unsigned char dummy;
dummy = SCI1S1; //read status flags
 
- you should shorten  the interrupt routine. Make sure that your routine does not take more than < 10% of the time. If it does, and thats what it seems to be doing, then you must shorten it down.
 
Regards,
Ake
0 Kudos
Reply

686 Views
tonyp
Senior Contributor II
Other than the always first suspect (buggy code), a couple of guesses:

1. You're doing too much inside the interrupt handler (especially if using a fast baud rate), and by the time you're done, another interrupt is already pending.

2. Similarly, TX interrupts will fire continuously even after the end of the message if not correctly turned off when done sending the message.  At a fast baud rate you'll be servicing interrupt after interrupt with no time left for other code in between.  By the way, depending on the MCU speed and the code that must execute between successive characters (RX or TX), it's possible that you will get better throughput at a lower baud rate than the highest possible one.

0 Kudos
Reply

686 Views
peg
Senior Contributor IV
Hello and welcome to the fora, Lydia.

It seems you are possibly on the right track with your reasoning.
Any chance of posting some of the relevant parts of your code so we can take a look and offer some help?

0 Kudos
Reply