Failing to return from interrupt (newbi question) - MC9S08QE128

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

Failing to return from interrupt (newbi question) - MC9S08QE128

2,935 Views
hek
Contributor I
Hi Folks,

Im new to the arcitecure and Ide (CodeWarrior) and find this very confusing... I have a timer interrupt that should fire every 1ms. When I set a break point in TPM_ISR, I get there but when Im about to return from the ISR (at the RTI instruction) I get the error message "Error: At location 0299 -
Error: Attempt to use invalid or uninitialized memory". Has anyone a clue about the problem here? Where could the problem be?

The ISR (probably not the problem):
void interrupt VectorNumber_Vtpm3ch3 TPM_ISR(void)
{
  m_time++; 

  TPM3C3SC_CH3F;      // Clears timer flag
  TPM3C3SC_CH3F = 0;
}

By the way, Im not running on the Full Chip simulation, not real hardware.

Best regards
Henrik


Message Edited by hek on 2008-02-06 12:33 PM
Labels (1)
0 Kudos
Reply
8 Replies

907 Views
fabio
Contributor IV
Hi Henrik,

It is not clear if you are using Full Chip Simulation (FCS) or In-Circuit Debugging.

According to your description, it looks like you are using FCS. The problem here is that you are probabli trying to increment a non-initialized variable (m_time).

You could try to initialize m_time in the beginning of your code. This will probably solve your problem.

Best regards,


0 Kudos
Reply

907 Views
bigmac
Specialist III
Hello Henrik,
 
Further to Fabio's insight -
 
I assume that the variable m_time is global.  If so, during the ANSI initialisation process, the variable should have been assigned a default value of zero.  However, it is also possible that, when you created the CW project, you elected not to allow ANSI initialisation code, and this may account for your problem.
 
If this is the situation, and few variables are affected by the lack of general initialisation, you might explicitly initialise the variable within main() function
 
The "uninitialised memory" error message would be applicable to full chip simulation only.
 
Regards,
Mac
 
0 Kudos
Reply

907 Views
Ake
Contributor II
Hi,
It is possible that you have enabled more interrupts that you have not written any code for.
So when an interrupt occurs, there is no code to execute there.

I also saw that you have no reset interrupt flag in your code. So each time you exit the interrupt, you will immediatly get another one.

Regards,
Ake
 
0 Kudos
Reply

907 Views
hek
Contributor I
Thanks for your replies!

Actually, the problem was that I for some reason had the Timer Interrupt activated... If i cleared the TOIE bit everything worked just fine. :smileyhappy: m_time is not a global variable (and it is initialized), its a static member...

I was using Full Chip SImulation

Best regards
Henrik
0 Kudos
Reply

907 Views
bigmac
Specialist III
Hello Henrik,
 
This highlights the need to initialize all interrupt vectors, whether the interrupt is in use, or not, just in case a spurious interrupt should occur for whatever reason.  As a minimum requirement, all unused vectors should point to an RTI instruction, or an empty ISR in C.  Additionally, you might consider the possibility of identifying the interrupt source to assist with identification of the "unused " interrupt event, for debug purposes.
 
Regards,
Mac
 
0 Kudos
Reply

907 Views
hek
Contributor I
True true. I tried to identify the interrup in True-Time Simulator, but didnt find the correct panel i suppose...
0 Kudos
Reply

907 Views
fabio
Contributor IV
I agree with Bigmac regarding spurious interrups, but spurious interrupt in an FCS session ? I don't think so...

Hek, probably there is another thing wrong with your code ...

Regards,


Message Edited by fabio on 2008-02-07 10:15 AM
0 Kudos
Reply

907 Views
bigmac
Specialist III
Hello,
 
Since the TPM modules are simulated, and can generate interrupts within an FCS session, I guess this can be classified as "spurious", if unintended but caused by a programming error, as seems to be the case in question.  This type of error still needs to be weeded out, whether in FCS, or during real operation in a debug session.
 
To specifically identify the source of each interrupt event would seem to require a separate ISR for every interrupt vector, at least for the QE128 device.  For the unused interrupts, presumably a byte value to represent the interrupt source would need to be dumped in a variable, for later analysis.  In many instances, the ISR might need to clear all flags associated with that interrupt, to prevent repeated interrupts occurring for the single spurious event.
 
Regards,
Mac
 
0 Kudos
Reply