Some problems with TimeBase on AP32

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

Some problems with TimeBase on AP32

1,228 Views
B_Conf
Contributor I
Hello,
       I`m using the 908AP32CFBE, and I am using CW 6.1. with PE.
  I put a bean that interrupts every second and it increase a global variable, then  it compares the global variable with another.
Here is part of the code
 
 void Base_de_tiempo_OnInterrupt(void)
{
  byte AuxPrev,err;
  word SND;
  float frec,per,Vrms,Irms,PF,aux3;
  Nosep Dato;
 
  //WDog1_Clear();
  base++;
 
  if(base==tiempoentremuestras)
  {
       Muestreo_C_fase_Disable();
       Muestreo_S_fase_Disable();
       Base_de_tiempo_Disable();
       tecla=FALSE;
       KBSCR_ACK=1;              //Coloco nuevamente KEYF en 0
       KBSCR_IMASK=0;   //Habilito nuevamente las interrupciones de teclado
       err=LCD_SendBlock("Paso 1",6,&SND);
       while (err!=ERR_OK);
       AD3204_Disable();
       err=LCD_SendBlock("Paso 2",6,&SND);
       while (err!=ERR_OK);
       LCD_SendChar(12);
       Cpu_Delay100US(50);
      /**************************************************
      **              Para Debug                      ***
      **************************************************/
       err=LCD_SendBlock("Interrupcion",12,&SND);
       while (err!=ERR_OK);
       err=TRUE;
        for(;:smileywink:
        {
          if (tecla)
          break;
        }
        tecla=FALSE; 
        KBSCR_ACK=1;              //Coloco nuevamente KEYF en 0
        KBSCR_IMASK=0;   //Habilito nuevamente las interrupciones de teclado
       
           
       /**************************************************
      **                FIN Debug                      ***
      **************************************************/
      
...
     ...
}
 

When the condition is true, (base=tiempoentremuestras) the uC freezes and I have to reset it.
I simulated it, but it worked fine, so I m not sure where could be the problem.

Please, if someone can give me an advice , I will appreciate a lot.

Thanks
BConf

Labels (1)
0 Kudos
3 Replies

333 Views
bigmac
Specialist III
Hello BConf,
 
I three places you have code similar to the following -
 
      err = LCD_SendBlock( "Paso 1", 6, &SND);
      while (err != ERR_OK);
 
Unless the value ERR_OK is immediately returned by the LCD_SendBlock() function, you will enter a wait loop.  Since err is a local variable, once entered the wait loop can never exit.
 
Even if you had intended that the variable be global, and the value updated within another ISR, this also seems problematic.  Assuming your posted code actually represents ISR code for a timer interrupt, further interrupts will be globally disabled by default (to prevent multiple nested interrupts).  Again, the value of the variable could not change to exit the loop.
 
Rule #1:  Never place wait loops, or even delay loops, within ISR code - always exit an ISR as quickly as possible.
Rule #2:  Be wary about calling other functions from within an ISR - the called functions might contain wait loops or delay loops.
 
Under simulation conditions, it is possible that the value of err was such that the loop did not.
 
Regards,
Mac
 


Message Edited by bigmac on 2008-09-25 12:56 AM
0 Kudos

333 Views
B_Conf
Contributor I
Hello Bigmac:
                       You are right, I didn't realise that the update of err is mising, so I'm going to add that update to avoid infinites loop.
  On the other hand, I would like to know, why is it  important to exit of an ISR as soon as possible, if
I disable the Bean when the condition is true?. (My code).
While this interrupt is running but the condition is false, I have another timer, interrupting every 200 uS, it means that the interrupts are not disabled by default, at least it seems to work on that way, so I don't understand what you mean, in fact I don't understand how CW manage the ISR's.
 
Thank you very much for your support
Regards
B_Conf.
 
0 Kudos

333 Views
bigmac
Specialist III
Hello BConf,
 
I might suggest you download the document CPU08RM CPU08 Reference Manual from the Freescale website.  Section 3 contains more detailed information about the operation of Resets and Interrupts.
 
Unless nested interrupts have been specifically catered for within the code, only a single interrupt may be processed at any time.  One interrupt must exit before another interrupt can commence processing.  Allowing for nested interrupts within a HC908 MCU does require some code and processing overheads, and will likely require considerably more stack space.  Usually it is used only in special circumstances.  I do not know whether PE provides nested interrupts.
 
Assuming that there is no interrupt nesting, if your current processing were to exceed 200 microseconds duration, you would miss one or more of the 200us timer interrupts.  This is why the ISR processing should be as short as possible.
 
Regards,
Mac
 


Message Edited by bigmac on 2008-09-25 11:05 PM
0 Kudos