Minidragon C code limit /Codewarrior serialmonitor

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Minidragon C code limit /Codewarrior serialmonitor

jeffm-4
Hello,
I am using a Minidragon plus2 with mixed C & assembly as shown in the book:
"Learning C by example" & have seemingly run into the max C code limit.

Using special edition version of Codewarrior with serial monitor
My C code is growing & now now during flash programming at approx 14210 bytes size the Hiwave debugger indicates:
 Link Error   : L1102: Out of allocation space in segment ROM_C000 at address 0xF769  Link Error   : Link failed
F769 is 63337 decimal!!
What is the general procedure to get the full 32K limit

Thanks
Jeff Morrison
Bend Oregon
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Minidragon C code limit /Codewarrior serialmonitor

Edward Karpicz
Hi

You need either use banked memory model, or edit *.prm file. For some reason
if you specify small memory model, only ROM_C000 segment is used for
constants and code placement. Find where ROM_4000 is commented out and
uncomment it. Also enable compiler switch which is specified there in prm
file.

Edward

----- Original Message -----
From: <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, January 19, 2011 2:41 AM
Subject: [68HC12] Minidragon C code limit /Codewarrior serialmonitor


> Hello,
> I am using a Minidragon plus2 with mixed C & assembly as shown in the
> book:
> "Learning C by example" & have seemingly run into the max C code limit.
>
> Using special edition version of Codewarrior with serial monitor
> My C code is growing & now now during flash programming at approx 14210
> bytes size the Hiwave debugger indicates:
> Link Error   : L1102: Out of allocation space in segment ROM_C000 at
> address 0xF769  Link Error   : Link failed
> F769 is 63337 decimal!!
> What is the general procedure to get the full 32K limit
>
> Thanks
> Jeff Morrison
> Bend Oregon
> [hidden email]
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Minidragon C code limit /Codewarrior serialmonitor

jeffm-4
In reply to this post by jeffm-4


Thanks Edward,
In the file serial monitor linker.prm I was able to find the ROM_4000 area & change it, but am not sure about how to use the compiler option "-OnB=b" specified in the same file.
Im in CW/ edit / HCS12 serialmonitor settings /compiler for HC12.
I dont see anywhere to select anything to creat option: -OnB=b

Where is this option set?

Interestingly enough, I can now go to 16K before running out of memory - just changing the ROM_4000
Jeff

Reply | Threaded
Open this post in threaded view
|

Re: Re: Minidragon C code limit /Codewarrior serialmonitor

Edward Karpicz
Standard settings->Compiler. You should see compiler command line switches
string. Copy paste this -OnB=b to the end of this string. Make sure to
insert space before "-".

Edward

----- Original Message -----
From: <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, January 19, 2011 10:37 PM
Subject: [68HC12] Re: Minidragon C code limit /Codewarrior serialmonitor


>
>
> Thanks Edward,
> In the file serial monitor linker.prm I was able to find the ROM_4000 area
> & change it, but am not sure about how to use the compiler option "-OnB=b"
> specified in the same file.
> Im in CW/ edit / HCS12 serialmonitor settings /compiler for HC12.
> I dont see anywhere to select anything to creat option: -OnB=b
>
> Where is this option set?
>
> Interestingly enough, I can now go to 16K before running out of memory -
> just changing the ROM_4000
> Jeff
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Minidragon C code limit /Codewarrior serialmonitor

jeffm-4
In reply to this post by jeffm-4
Alright the compiler option is in.  
I can fill the program up with bloat (strings) till it fails at"

Link Error   : L1102: Out of allocation space in segment ROM_4000 at address 0x7FED    Link Error   : Link failed   (32,749) is this the actual code size trying to load to the flash?
If I reduce the code by 1 byte, there is no link error, but Hiwave reports 16,386 loaded. Im a bit confused.  Oh well, its probably enough to finish!

Thank you Edward.

Jeff







Reply | Threaded
Open this post in threaded view
|

Re: Re: Minidragon C code limit /Codewarrior serialmonitor

Edward Karpicz
Since there are two pieces of memory, 16k @4000 and 16k at $c000, no object
can be bigger than 16k. Try defining two big strings. Keep in mind that
linker will not link unused objects, so both string objects should be
referenced from your code.

Edward

----- Original Message -----
From: <[hidden email]>
To: <[hidden email]>
Sent: Thursday, January 20, 2011 9:22 AM
Subject: [68HC12] Re: Minidragon C code limit /Codewarrior serialmonitor


> Alright the compiler option is in.
> I can fill the program up with bloat (strings) till it fails at"
>
> Link Error   : L1102: Out of allocation space in segment ROM_4000 at
> address 0x7FED    Link Error   : Link failed   (32,749) is this the actual
> code size trying to load to the flash?
> If I reduce the code by 1 byte, there is no link error, but Hiwave reports
> 16,386 loaded. Im a bit confused.  Oh well, its probably enough to finish!
>
> Thank you Edward.
>
> Jeff
>
>
>
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Re: Minidragon C code limit /Codewarrior serialmonitor

Edward Karpicz
In reply to this post by jeffm-4
Special edition limit message is different.

Edward

----- Original Message -----
From: "Edward Karpicz" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, January 20, 2011 12:54 PM
Subject: Re: [68HC12] Re: Minidragon C code limit /Codewarrior serialmonitor


> Since there are two pieces of memory, 16k @4000 and 16k at $c000, no
> object can be bigger than 16k. Try defining two big strings. Keep in mind
> that linker will not link unused objects, so both string objects should be
> referenced from your code.
>
> Edward
>
> ----- Original Message -----
> From: <[hidden email]>
> To: <[hidden email]>
> Sent: Thursday, January 20, 2011 9:22 AM
> Subject: [68HC12] Re: Minidragon C code limit /Codewarrior serialmonitor
>
>
>> Alright the compiler option is in.
>> I can fill the program up with bloat (strings) till it fails at"
>>
>> Link Error   : L1102: Out of allocation space in segment ROM_4000 at
>> address 0x7FED    Link Error   : Link failed   (32,749) is this the
>> actual code size trying to load to the flash?
>> If I reduce the code by 1 byte, there is no link error, but Hiwave
>> reports 16,386 loaded. Im a bit confused.  Oh well, its probably enough
>> to finish!
>>
>> Thank you Edward.
>>
>> Jeff
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Not returning from Interrupt

Jerry Fields





Hello,
 
I do not have my source code with me to post, however, I was hoping someone can help me with a quick tip, or something I might be over looking.
 
I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I am new to using interrupts(to a degree), so please bare with me. I am running through an infinite loop in my software, but during that loop, I enable the ATD interrupt. A short time after the ATD interrupt is enabled, it branches off properly, (I believe after it finishes a conversion), and executes the ATD interrupt routine I have wrote, (So far, so good).
 
After the ATD interrupt is serviced, however, it does not return back to the infinite loop. I have traced it through, and I noticed that the Program Counter is NOT getting pushed onto the stack right before the leaves the infinite loop to service the interrupt.
 
Does anyone (based on the information above) have any idea why the PC is NOT getting pushed onto the stack right before it leaves to service the interrupt?
 
Thanks in advance for any help.
Jerry

 
 
 
 
 
 

 

     

[Non-text portions of this message have been removed]



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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/68HC12/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/68HC12/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply | Threaded
Open this post in threaded view
|

Re: Not returning from Interrupt

Edward Karpicz
Failure to clear interrupt flag is #1 for not returning from interrupt. 2nd
is wrong return from ISR instruction (should be RTI, and not RTS or RTC),
but in this case program will crash soon and BDM debugger should tell you
something about this.
So what is the setting of AFFC bit and how are you clearing ATD interrupt
flag?

Edward

----- Original Message -----
From: "Jerry Fields" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, January 20, 2011 6:42 PM
Subject: [68HC12] Not returning from Interrupt


>
>
>
>
>
> Hello,
>
> I do not have my source code with me to post, however, I was hoping
> someone can help me with a quick tip, or something I might be over
> looking.
>
> I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
> am new to using interrupts(to a degree), so please bare with me. I am
> running through an infinite loop in my software, but during that loop, I
> enable the ATD interrupt. A short time after the ATD interrupt is enabled,
> it branches off properly, (I believe after it finishes a conversion), and
> executes the ATD interrupt routine I have wrote, (So far, so good).
>
> After the ATD interrupt is serviced, however, it does not return back to
> the infinite loop. I have traced it through, and I noticed that the
> Program Counter is NOT getting pushed onto the stack right before the
> leaves the infinite loop to service the interrupt.
>
> Does anyone (based on the information above) have any idea why the PC is
> NOT getting pushed onto the stack right before it leaves to service the
> interrupt?
>
> Thanks in advance for any help.
> Jerry
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: Not returning from Interrupt

Tennies, Joseph C.-2
In reply to this post by Jerry Fields
That is odd. I can't say I ever LOOKED for the PC on the stack. It MAY
be handled by a register in the interrupt module of the processor.

One thing that has bitten me a couple times with interrupts on the HC12
is that many have flags that need to be cleared or the interrupt will
just retrigger. I would look at the data sheet for you particular model
and see if there's a flag you need to clear (like a Converstion Complete
Interrupt Flag (CCIF)). The datasheet has a list of the particular flag
that triggers the interrupt in a table that lists the interrupt vector.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Jerry Fields
Sent: Thursday, January 20, 2011 10:42 AM
To: [hidden email]
Subject: [68HC12] Not returning from Interrupt






Hello,
 
I do not have my source code with me to post, however, I was hoping
someone can help me with a quick tip, or something I might be over
looking.
 
I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
am new to using interrupts(to a degree), so please bare with me. I am
running through an infinite loop in my software, but during that loop, I
enable the ATD interrupt. A short time after the ATD interrupt is
enabled, it branches off properly, (I believe after it finishes a
conversion), and executes the ATD interrupt routine I have wrote, (So
far, so good).
 
After the ATD interrupt is serviced, however, it does not return back to
the infinite loop. I have traced it through, and I noticed that the
Program Counter is NOT getting pushed onto the stack right before the
leaves the infinite loop to service the interrupt.
 
Does anyone (based on the information above) have any idea why the PC is
NOT getting pushed onto the stack right before it leaves to service the
interrupt?
 
Thanks in advance for any help.
Jerry

 
 
 
 
 
 

 

     

[Non-text portions of this message have been removed]



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

Yahoo! Groups Links



Reply | Threaded
Open this post in threaded view
|

RE: Not returning from Interrupt

justin lucas

Have to agree about pushing the PC onto the stack.  My professor always told us to avoid using the stack unless you absolutley need it.
If you have to use it, when you add the PUSH command, be sure to add the PULL command right after, then put your instructions in between them.
 
You might check your ISR (interrupt service routine) to see if you have cleared the interrupt flag and if you have a RTI (return from Interrupt).
Here is an example of a timer interrupt from a friend of mine using M68HC11E for a different application.  Notice the clearing of interrupts.
 ...
 
ISR_TIMER                     ;timer interrup routine
      ldd TOC2                ;load TOC2
      addd  #$07D0            ;add another millisecond for timer count
      std   TOC2
      ldaa #$40               ;clearing interrupt by setting bit
      staa  TFLG1             ;clearing interrupt OCI2
      ldab PORTB              ;load current value in PORTB (lower digits), current value of PORTB determines contents of count
                              ;regardless of green switch position, i.e., start/stop in middle of program run
      incb                    ;count up B
      stab count              ;store this value for updating
      cli                     ;clear interrupt in CC register
      rti                     ;return from interrupt
                              ;lesson found during interrupt, do not JMP/JSR to any routine, just do the interrupt and get out!

Good luck.
 
Justin
 
"In theory, there is no difference between theory and practice. But, in practice, there is. "
--Yogi Berra/Jan L.A. van de Snepscheut--


 


To: [hidden email]
From: [hidden email]
Date: Fri, 27 May 2011 18:03:32 -0500
Subject: RE: [68HC12] Not returning from Interrupt


 



That is odd. I can't say I ever LOOKED for the PC on the stack. It MAY
be handled by a register in the interrupt module of the processor.

One thing that has bitten me a couple times with interrupts on the HC12
is that many have flags that need to be cleared or the interrupt will
just retrigger. I would look at the data sheet for you particular model
and see if there's a flag you need to clear (like a Converstion Complete
Interrupt Flag (CCIF)). The datasheet has a list of the particular flag
that triggers the interrupt in a table that lists the interrupt vector.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf
Of Jerry Fields
Sent: Thursday, January 20, 2011 10:42 AM
To: [hidden email]
Subject: [68HC12] Not returning from Interrupt

Hello,

I do not have my source code with me to post, however, I was hoping
someone can help me with a quick tip, or something I might be over
looking.

I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
am new to using interrupts(to a degree), so please bare with me. I am
running through an infinite loop in my software, but during that loop, I
enable the ATD interrupt. A short time after the ATD interrupt is
enabled, it branches off properly, (I believe after it finishes a
conversion), and executes the ATD interrupt routine I have wrote, (So
far, so good).

After the ATD interrupt is serviced, however, it does not return back to
the infinite loop. I have traced it through, and I noticed that the
Program Counter is NOT getting pushed onto the stack right before the
leaves the infinite loop to service the interrupt.

Does anyone (based on the information above) have any idea why the PC is
NOT getting pushed onto the stack right before it leaves to service the
interrupt?

Thanks in advance for any help.
Jerry



[Non-text portions of this message have been removed]

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

Yahoo! Groups Links



     

[Non-text portions of this message have been removed]



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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/68HC12/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/68HC12/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply | Threaded
Open this post in threaded view
|

RE: Not returning from Interrupt

James M. Knox
At 12:56 PM 5/28/2011 +0000, you wrote:

>Have to agree about pushing the PC onto the stack.  My professor
>always told us to avoid using the stack unless you absolutley need it.

For a VERY introductory course (first few weeks) that may be good
advice.  But after that... well, all modern languages (and modern
programming practices) use the stack(s) for virtually every piece of
temporary storage (non-static).  It is absolutely true that you can
develop some of the most hard to debug code imaginable with
stack/interrupt code.  But that's not a reason not to use it - just a
reason to learn to use it correctly!  [Okay... soapbox mode OFF. <G>]

>After the ATD interrupt is serviced, however, it does not return back to
>the infinite loop. I have traced it through, and I noticed that the
>Program Counter is NOT getting pushed onto the stack right before the
>leaves the infinite loop to service the interrupt.
>
>Does anyone (based on the information above) have any idea why the PC is
>NOT getting pushed onto the stack right before it leaves to service the
>interrupt?

*If* it is true that the PC address is not showing up on the stack,
is the stack itself correct?  The PC return address is the FIRST
thing pushed when an interrupt occurs, and it goes to the stack
address.  So (pure speculation here) one way I could envision your
problem occurring would be this:

         You have RAM memory allocated to, for example, the
                 first 4K bytes ($1000)

         You set the stack pointer to $1000.

         Bingo - interrupt occurs and you get the registers
                 saved, but no PC return address.

Reason - there *is* no RAM at $1000.  The SP *should* be initialized to $0FFF.

[The above is just a guess, but it's one error that would match your
description of the problem.]

BTW, if you are debugging without sophisticated gear (that can
monitor HARDWARE addresses (not just variable read/writes), then add
a couple of lines to your code.  Right after you initialize the
stack, load some 16 bit register with an unusual value (like $1234)
and just push it onto the stack and leave it there.  Then, anytime
you are snooping memory, you can check that first stack address
directly {the address to which you initialized the stack} and see if
that value is still there.  If it isn't, you are underflowing the stack!

                                 jmk


-----------------------------------------------
James M. Knox
TriSoft                        ph  512-385-0316
1300 Koenig Lane West          fax 512-371-5716
Suite 200
Austin, Tx 78756              [hidden email]
-----------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: Not returning from Interrupt

Edward Karpicz
In reply to this post by justin lucas
Additionally to James comments

> Here is an example of a timer interrupt from a friend of mine using
> M68HC11E for a different application.  Notice the clearing of interrupts.

What should one notice? The write to timer interrupt flags register TFLG1,
or CLI instruction usage in ISR? First is correct, second is pointless and
useless. I mean following line of code. It should be removed:

>      cli                     ;clear interrupt in CC register



Regarding initial SP value. On HC11 stack pointer points to one byte below
the last byte pushed (or to free or unused byte on the stack). So if RAM
ends at 0xFFF, you init SP with 0xFFF. On HC12 and S12(X), stack pointer
points to last byte pushed. So if RAM ends at 0xFFF, you normaly init SP
with one address above that, or 0x1000.

Edward

Reply | Threaded
Open this post in threaded view
|

RE: Not returning from Interrupt (Figure this one out!)

Jerry Fields
In reply to this post by Edward Karpicz

OK friends, I never solved the problem below. I ended up walking away from it out of frustration. OK, I am trying trying again! In my email below, I may have been incorrect in saying that the PC is not getting pushed onto the stack.....
 
 Present day problem:
 
I am using the ECT (this time) on a mc9s12. I am doing an input capture on CH01, and everything is fine there. The program is running through an infinite loop, but when a wave form is detected for input capture, an interrupt occurs, and it branches off to the ISR. Again, so far so good.
 
After I get to the ISR, I am doing an immediate sei to prevent any additional interrupts, and after its done doing its work, I am clearing the ECT interrupt flag, TFLG1 bit 0. Please correct any of the above if need be, but I don’t think the problem has anything to do with what flags im clearing or not clearing.
 
 
The problem I believe, is how the registers are being pushed onto, and then pulled off of the stack during the attempted return from the ISR. OK, while I’m in the infinite (do nothing) for loop, the registers read as followed:
 
PC:   C097
SP:   3DFA
X:     080A
Y      0800
D:     0700
CCR: 0000
 
 
As soon as the interrupt occurs, and it jumps to the ISR, it pushes the registers onto the stack as follows, (I viewed this in a "data window" that the Development environment provides):
 
After the jump to the ISR, all the registers are the same except for the PC and SP. The SP now has 3DEF.   3DFA - 3DEF = B
 
So it looks like the stack had 11 bytes pushed onto it. I would expect 10 or 12 depending on weather the CCR gets pushed onto it or not. Not sure why it moved 11.  ??
 
Viewing the stack in memory, it now looks like this:
 
 
 
Starting at 3DEF, and going up:
 
3D  FA  00  00  07  08  0A  08  00  C0  97  If I line these memory locations up with the orginal register values, it looks like this:
 
 
PC:   C097       C097
SP:   3DFA       0800
X:     080A       080A
Y      0800       0007
D:     0700      FA00
CCR: 0000         3D
 
As you can see, the values don't line up, and the D register's value has even been reversed.
 
 
After the ISR is finished, I execute a RTI, and this is what is popped off of the stack into the registers:
 
 
PC:   0800
SP:   3DF8
X:     0007
Y      080A
D:     00FA
CCR: 003D
 
No only did it push the values onto the stack incorrectly, but it pulled it off incorrectly also. I was tracing through the program, and while it was in the ISR, I manually replaced the 08 00 value on the stack with C0 97, (the proper return address), and when it got to the RTI, it properly jumped back to the infinite loop.
 
 
HELP!
 
Any Ideas?
 
 
 
 
 

 



To: [hidden email]
From: [hidden email]
Date: Thu, 20 Jan 2011 19:44:51 +0200
Subject: Re: [68HC12] Not returning from Interrupt

 
Failure to clear interrupt flag is #1 for not returning from interrupt. 2nd
is wrong return from ISR instruction (should be RTI, and not RTS or RTC),
but in this case program will crash soon and BDM debugger should tell you
something about this.
So what is the setting of AFFC bit and how are you clearing ATD interrupt
flag?

Edward

----- Original Message -----
From: "Jerry Fields" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, January 20, 2011 6:42 PM
Subject: [68HC12] Not returning from Interrupt

>
>
>
>
>
> Hello,
>
> I do not have my source code with me to post, however, I was hoping
> someone can help me with a quick tip, or something I might be over
> looking.
>
> I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
> am new to using interrupts(to a degree), so please bare with me. I am
> running through an infinite loop in my software, but during that loop, I
> enable the ATD interrupt. A short time after the ATD interrupt is enabled,
> it branches off properly, (I believe after it finishes a conversion), and
> executes the ATD interrupt routine I have wrote, (So far, so good).
>
> After the ATD interrupt is serviced, however, it does not return back to
> the infinite loop. I have traced it through, and I noticed that the
> Program Counter is NOT getting pushed onto the stack right before the
> leaves the infinite loop to service the interrupt.
>
> Does anyone (based on the information above) have any idea why the PC is
> NOT getting pushed onto the stack right before it leaves to service the
> interrupt?
>
> Thanks in advance for any help.
> Jerry
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

     

[Non-text portions of this message have been removed]



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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/68HC12/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/68HC12/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply | Threaded
Open this post in threaded view
|

Re: Not returning from Interrupt (Figure this one out!)

Michael-465
Can you post the source code? Or at least the ISR?  Difficult to say what may be going on in the ISR.  here are a couple of things to check if you haven't already done so:

1. Remove the SEI instruction in your ISR. The CCR 'I' flag automatically gets set when an interrupt occurs and does not get cleared by the MCU until the RTI instruction, so no other interrupts are possible unless you specifically do a CLI inside the ISR (be very careful when doing so - infinite ISR calls possible)
2. Make sure you are clearing the TFLG1 bit correctly - most flags require a write with '1' to clear them and an additional data register read to complete the clear
3. Do you do a CLI anywhere?  You shouldn't need to.
4. My favorite mistake is to overwrite the stack with variables...

Hope any of this helps.  If not post your ISR and I'll look at that.
Mike

--- In [hidden email], Jerry Fields <electronic_tech1@...> wrote:

>
>
> OK friends, I never solved the problem below. I ended up walking away from it out of frustration. OK, I am trying trying again! In my email below, I may have been incorrect in saying that the PC is not getting pushed onto the stack.....
>  
>  Present day problem:
>  
> I am using the ECT (this time) on a mc9s12. I am doing an input capture on CH01, and everything is fine there. The program is running through an infinite loop, but when a wave form is detected for input capture, an interrupt occurs, and it branches off to the ISR. Again, so far so good.
>  
> After I get to the ISR, I am doing an immediate sei to prevent any additional interrupts, and after its done doing its work, I am clearing the ECT interrupt flag, TFLG1 bit 0. Please correct any of the above if need be, but I don't think the problem has anything to do with what flags im clearing or not clearing.
>  
>  
> The problem I believe, is how the registers are being pushed onto, and then pulled off of the stack during the attempted return from the ISR. OK, while I'm in the infinite (do nothing) for loop, the registers read as followed:
>  
> PC:   C097
> SP:   3DFA
> X:     080A
> Y      0800
> D:     0700
> CCR: 0000
>  
>  
> As soon as the interrupt occurs, and it jumps to the ISR, it pushes the registers onto the stack as follows, (I viewed this in a "data window" that the Development environment provides):
>  
> After the jump to the ISR, all the registers are the same except for the PC and SP. The SP now has 3DEF.   3DFA - 3DEF = B
>  
> So it looks like the stack had 11 bytes pushed onto it. I would expect 10 or 12 depending on weather the CCR gets pushed onto it or not. Not sure why it moved 11.  ??
>  
> Viewing the stack in memory, it now looks like this:
>  
>  
>  
> Starting at 3DEF, and going up:
>  
> 3D  FA  00  00  07  08  0A  08  00  C0  97  If I line these memory locations up with the orginal register values, it looks like this:
>  
>  
> PC:   C097       C097
> SP:   3DFA       0800
> X:     080A       080A
> Y      0800       0007
> D:     0700      FA00
> CCR: 0000         3D
>  
> As you can see, the values don't line up, and the D register's value has even been reversed.
>  
>  
> After the ISR is finished, I execute a RTI, and this is what is popped off of the stack into the registers:
>  
>  
> PC:   0800
> SP:   3DF8
> X:     0007
> Y      080A
> D:     00FA
> CCR: 003D
>  
> No only did it push the values onto the stack incorrectly, but it pulled it off incorrectly also. I was tracing through the program, and while it was in the ISR, I manually replaced the 08 00 value on the stack with C0 97, (the proper return address), and when it got to the RTI, it properly jumped back to the infinite loop.
>  
>  
> HELP!
>  
> Any Ideas?
>  
>  
>  
>  
>  
>
>  
>
>
>
> To: [hidden email]
> From: karpicz@...
> Date: Thu, 20 Jan 2011 19:44:51 +0200
> Subject: Re: [68HC12] Not returning from Interrupt
>
>  
> Failure to clear interrupt flag is #1 for not returning from interrupt. 2nd
> is wrong return from ISR instruction (should be RTI, and not RTS or RTC),
> but in this case program will crash soon and BDM debugger should tell you
> something about this.
> So what is the setting of AFFC bit and how are you clearing ATD interrupt
> flag?
>
> Edward
>
> ----- Original Message -----
> From: "Jerry Fields" <electronic_tech1@...>
> To: <[hidden email]>
> Sent: Thursday, January 20, 2011 6:42 PM
> Subject: [68HC12] Not returning from Interrupt
>
> >
> >
> >
> >
> >
> > Hello,
> >
> > I do not have my source code with me to post, however, I was hoping
> > someone can help me with a quick tip, or something I might be over
> > looking.
> >
> > I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
> > am new to using interrupts(to a degree), so please bare with me. I am
> > running through an infinite loop in my software, but during that loop, I
> > enable the ATD interrupt. A short time after the ATD interrupt is enabled,
> > it branches off properly, (I believe after it finishes a conversion), and
> > executes the ATD interrupt routine I have wrote, (So far, so good).
> >
> > After the ATD interrupt is serviced, however, it does not return back to
> > the infinite loop. I have traced it through, and I noticed that the
> > Program Counter is NOT getting pushed onto the stack right before the
> > leaves the infinite loop to service the interrupt.
> >
> > Does anyone (based on the information above) have any idea why the PC is
> > NOT getting pushed onto the stack right before it leaves to service the
> > interrupt?
> >
> > Thanks in advance for any help.
> > Jerry
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>      
>
> [Non-text portions of this message have been removed]
>


Reply | Threaded
Open this post in threaded view
|

RE: Re: Not returning from Interrupt (Figure this one out!)

Jerry Fields

Thanks for the info on the un-needed sei. I removed it, but it didn't help. I do not call cli or sei anywhere else btw.
 
Here is my ISR code.
 
 
void tc1_isr(void)
{
 
       asm("sei");
       asm("ldd 0x05");         // Loading D with the input capture value of TC0
       asm("std 0x3400");     // Storing D in RAM @ address 3400
       asm("ldaa #0x01");
       asm("staa 0x4e");       //Clearing TFLG1, because an interrupt has occured
       asm("rti");
}
 
 
Is it normal for the registers to get pushed onto the stack in the wrong order? Or like in the case of register D, have its contents reversed? And then when I do the rti, it pops them off in the wrong order too. i.e. Y ending up with the contents of X after the pop.
 
Thanks again for your help BTW.
 



To: [hidden email]
From: [hidden email]
Date: Wed, 20 Jul 2011 15:15:51 +0000
Subject: [68HC12] Re: Not returning from Interrupt (Figure this one out!)


 



Can you post the source code? Or at least the ISR? Difficult to say what may be going on in the ISR. here are a couple of things to check if you haven't already done so:

1. Remove the SEI instruction in your ISR. The CCR 'I' flag automatically gets set when an interrupt occurs and does not get cleared by the MCU until the RTI instruction, so no other interrupts are possible unless you specifically do a CLI inside the ISR (be very careful when doing so - infinite ISR calls possible)
2. Make sure you are clearing the TFLG1 bit correctly - most flags require a write with '1' to clear them and an additional data register read to complete the clear
3. Do you do a CLI anywhere? You shouldn't need to.
4. My favorite mistake is to overwrite the stack with variables...

Hope any of this helps. If not post your ISR and I'll look at that.
Mike

--- In [hidden email], Jerry Fields <electronic_tech1@...> wrote:

>
>
> OK friends, I never solved the problem below. I ended up walking away from it out of frustration. OK, I am trying trying again! In my email below, I may have been incorrect in saying that the PC is not getting pushed onto the stack.....
>
> Present day problem:
>
> I am using the ECT (this time) on a mc9s12. I am doing an input capture on CH01, and everything is fine there. The program is running through an infinite loop, but when a wave form is detected for input capture, an interrupt occurs, and it branches off to the ISR. Again, so far so good.
>
> After I get to the ISR, I am doing an immediate sei to prevent any additional interrupts, and after its done doing its work, I am clearing the ECT interrupt flag, TFLG1 bit 0. Please correct any of the above if need be, but I don't think the problem has anything to do with what flags im clearing or not clearing.
>
>
> The problem I believe, is how the registers are being pushed onto, and then pulled off of the stack during the attempted return from the ISR. OK, while I'm in the infinite (do nothing) for loop, the registers read as followed:
>
> PC: C097
> SP: 3DFA
> X: 080A
> Y 0800
> D: 0700
> CCR: 0000
>
>
> As soon as the interrupt occurs, and it jumps to the ISR, it pushes the registers onto the stack as follows, (I viewed this in a "data window" that the Development environment provides):
>
> After the jump to the ISR, all the registers are the same except for the PC and SP. The SP now has 3DEF. 3DFA - 3DEF = B
>
> So it looks like the stack had 11 bytes pushed onto it. I would expect 10 or 12 depending on weather the CCR gets pushed onto it or not. Not sure why it moved 11. ??
>
> Viewing the stack in memory, it now looks like this:
>
>
>
> Starting at 3DEF, and going up:
>
> 3D FA 00 00 07 08 0A 08 00 C0 97 If I line these memory locations up with the orginal register values, it looks like this:
>
>
> PC: C097 C097
> SP: 3DFA 0800
> X: 080A 080A
> Y 0800 0007
> D: 0700 FA00
> CCR: 0000 3D
>
> As you can see, the values don't line up, and the D register's value has even been reversed.
>
>
> After the ISR is finished, I execute a RTI, and this is what is popped off of the stack into the registers:
>
>
> PC: 0800
> SP: 3DF8
> X: 0007
> Y 080A
> D: 00FA
> CCR: 003D
>
> No only did it push the values onto the stack incorrectly, but it pulled it off incorrectly also. I was tracing through the program, and while it was in the ISR, I manually replaced the 08 00 value on the stack with C0 97, (the proper return address), and when it got to the RTI, it properly jumped back to the infinite loop.
>
>
> HELP!
>
> Any Ideas?
>
>
>
>
>
>
>
>
>
>
> To: [hidden email]
> From: karpicz@...
> Date: Thu, 20 Jan 2011 19:44:51 +0200
> Subject: Re: [68HC12] Not returning from Interrupt
>
>
> Failure to clear interrupt flag is #1 for not returning from interrupt. 2nd
> is wrong return from ISR instruction (should be RTI, and not RTS or RTC),
> but in this case program will crash soon and BDM debugger should tell you
> something about this.
> So what is the setting of AFFC bit and how are you clearing ATD interrupt
> flag?
>
> Edward
>
> ----- Original Message -----
> From: "Jerry Fields" <electronic_tech1@...>
> To: <[hidden email]>
> Sent: Thursday, January 20, 2011 6:42 PM
> Subject: [68HC12] Not returning from Interrupt
>
> >
> >
> >
> >
> >
> > Hello,
> >
> > I do not have my source code with me to post, however, I was hoping
> > someone can help me with a quick tip, or something I might be over
> > looking.
> >
> > I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
> > am new to using interrupts(to a degree), so please bare with me. I am
> > running through an infinite loop in my software, but during that loop, I
> > enable the ATD interrupt. A short time after the ATD interrupt is enabled,
> > it branches off properly, (I believe after it finishes a conversion), and
> > executes the ATD interrupt routine I have wrote, (So far, so good).
> >
> > After the ATD interrupt is serviced, however, it does not return back to
> > the infinite loop. I have traced it through, and I noticed that the
> > Program Counter is NOT getting pushed onto the stack right before the
> > leaves the infinite loop to service the interrupt.
> >
> > Does anyone (based on the information above) have any idea why the PC is
> > NOT getting pushed onto the stack right before it leaves to service the
> > interrupt?
> >
> > Thanks in advance for any help.
> > Jerry
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>
>
> [Non-text portions of this message have been removed]
>




     

[Non-text portions of this message have been removed]



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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/68HC12/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/68HC12/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply | Threaded
Open this post in threaded view
|

Re: Not returning from Interrupt (Figure this one out!)

Michael-465
I am not familiar with assembly in 'C' - I code strictly in assembly, but is the "ldd 0x05" correct?  TC0 is at '0050', I interpret your line as '0005' based on your "staa 0x4e" line which is 004E which is correct for TFLG1.  reading 'D' from 0005 will get you the low word of TCNT and TSCR1.  but that's not really your issue here...

you may want to try to clear the TFGL1 right away - it will not cause another interrupt since CCR-I is still set until the RTI.

are you aware of the TOF flag in TFLG2? Make sure your ISR is in the right spot and not pointed to by the TOF vector - speaking from experience here :)

what is your timer configuration?  What values to you set for TIOS, TSCR1/2, TCTL3/4

I'm not sure why your stack is getting jumbled.  I've never seen that...

--- In [hidden email], Jerry Fields <electronic_tech1@...> wrote:

>
>
> Thanks for the info on the un-needed sei. I removed it, but it didn't help. I do not call cli or sei anywhere else btw.
>  
> Here is my ISR code.
>  
>  
> void tc1_isr(void)
> {
>  
>        asm("sei");
>        asm("ldd 0x05");         // Loading D with the input capture value of TC0
>        asm("std 0x3400");     // Storing D in RAM @ address 3400
>        asm("ldaa #0x01");
>        asm("staa 0x4e");       //Clearing TFLG1, because an interrupt has occured
>        asm("rti");
> }
>  
>  
> Is it normal for the registers to get pushed onto the stack in the wrong order? Or like in the case of register D, have its contents reversed? And then when I do the rti, it pops them off in the wrong order too. i.e. Y ending up with the contents of X after the pop.
>  
> Thanks again for your help BTW.
>  
>
>
>
> To: [hidden email]
> From: mikeg@...
> Date: Wed, 20 Jul 2011 15:15:51 +0000
> Subject: [68HC12] Re: Not returning from Interrupt (Figure this one out!)
>
>
>  
>
>
>
> Can you post the source code? Or at least the ISR? Difficult to say what may be going on in the ISR. here are a couple of things to check if you haven't already done so:
>
> 1. Remove the SEI instruction in your ISR. The CCR 'I' flag automatically gets set when an interrupt occurs and does not get cleared by the MCU until the RTI instruction, so no other interrupts are possible unless you specifically do a CLI inside the ISR (be very careful when doing so - infinite ISR calls possible)
> 2. Make sure you are clearing the TFLG1 bit correctly - most flags require a write with '1' to clear them and an additional data register read to complete the clear
> 3. Do you do a CLI anywhere? You shouldn't need to.
> 4. My favorite mistake is to overwrite the stack with variables...
>
> Hope any of this helps. If not post your ISR and I'll look at that.
> Mike
>
> --- In [hidden email], Jerry Fields <electronic_tech1@> wrote:
> >
> >
> > OK friends, I never solved the problem below. I ended up walking away from it out of frustration. OK, I am trying trying again! In my email below, I may have been incorrect in saying that the PC is not getting pushed onto the stack.....
> >
> > Present day problem:
> >
> > I am using the ECT (this time) on a mc9s12. I am doing an input capture on CH01, and everything is fine there. The program is running through an infinite loop, but when a wave form is detected for input capture, an interrupt occurs, and it branches off to the ISR. Again, so far so good.
> >
> > After I get to the ISR, I am doing an immediate sei to prevent any additional interrupts, and after its done doing its work, I am clearing the ECT interrupt flag, TFLG1 bit 0. Please correct any of the above if need be, but I don't think the problem has anything to do with what flags im clearing or not clearing.
> >
> >
> > The problem I believe, is how the registers are being pushed onto, and then pulled off of the stack during the attempted return from the ISR. OK, while I'm in the infinite (do nothing) for loop, the registers read as followed:
> >
> > PC: C097
> > SP: 3DFA
> > X: 080A
> > Y 0800
> > D: 0700
> > CCR: 0000
> >
> >
> > As soon as the interrupt occurs, and it jumps to the ISR, it pushes the registers onto the stack as follows, (I viewed this in a "data window" that the Development environment provides):
> >
> > After the jump to the ISR, all the registers are the same except for the PC and SP. The SP now has 3DEF. 3DFA - 3DEF = B
> >
> > So it looks like the stack had 11 bytes pushed onto it. I would expect 10 or 12 depending on weather the CCR gets pushed onto it or not. Not sure why it moved 11. ??
> >
> > Viewing the stack in memory, it now looks like this:
> >
> >
> >
> > Starting at 3DEF, and going up:
> >
> > 3D FA 00 00 07 08 0A 08 00 C0 97 If I line these memory locations up with the orginal register values, it looks like this:
> >
> >
> > PC: C097 C097
> > SP: 3DFA 0800
> > X: 080A 080A
> > Y 0800 0007
> > D: 0700 FA00
> > CCR: 0000 3D
> >
> > As you can see, the values don't line up, and the D register's value has even been reversed.
> >
> >
> > After the ISR is finished, I execute a RTI, and this is what is popped off of the stack into the registers:
> >
> >
> > PC: 0800
> > SP: 3DF8
> > X: 0007
> > Y 080A
> > D: 00FA
> > CCR: 003D
> >
> > No only did it push the values onto the stack incorrectly, but it pulled it off incorrectly also. I was tracing through the program, and while it was in the ISR, I manually replaced the 08 00 value on the stack with C0 97, (the proper return address), and when it got to the RTI, it properly jumped back to the infinite loop.
> >
> >
> > HELP!
> >
> > Any Ideas?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > To: [hidden email]
> > From: karpicz@
> > Date: Thu, 20 Jan 2011 19:44:51 +0200
> > Subject: Re: [68HC12] Not returning from Interrupt
> >
> >
> > Failure to clear interrupt flag is #1 for not returning from interrupt. 2nd
> > is wrong return from ISR instruction (should be RTI, and not RTS or RTC),
> > but in this case program will crash soon and BDM debugger should tell you
> > something about this.
> > So what is the setting of AFFC bit and how are you clearing ATD interrupt
> > flag?
> >
> > Edward
> >
> > ----- Original Message -----
> > From: "Jerry Fields" <electronic_tech1@>
> > To: <[hidden email]>
> > Sent: Thursday, January 20, 2011 6:42 PM
> > Subject: [68HC12] Not returning from Interrupt
> >
> > >
> > >
> > >
> > >
> > >
> > > Hello,
> > >
> > > I do not have my source code with me to post, however, I was hoping
> > > someone can help me with a quick tip, or something I might be over
> > > looking.
> > >
> > > I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
> > > am new to using interrupts(to a degree), so please bare with me. I am
> > > running through an infinite loop in my software, but during that loop, I
> > > enable the ATD interrupt. A short time after the ATD interrupt is enabled,
> > > it branches off properly, (I believe after it finishes a conversion), and
> > > executes the ATD interrupt routine I have wrote, (So far, so good).
> > >
> > > After the ATD interrupt is serviced, however, it does not return back to
> > > the infinite loop. I have traced it through, and I noticed that the
> > > Program Counter is NOT getting pushed onto the stack right before the
> > > leaves the infinite loop to service the interrupt.
> > >
> > > Does anyone (based on the information above) have any idea why the PC is
> > > NOT getting pushed onto the stack right before it leaves to service the
> > > interrupt?
> > >
> > > Thanks in advance for any help.
> > > Jerry
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>      
>
> [Non-text portions of this message have been removed]
>


Reply | Threaded
Open this post in threaded view
|

RE: Re: Not returning from Interrupt (Figure this one out!)

Jerry Fields

Yes, sorry about that, the '05' was a typo. It should have been '50'.
 
OK, cleared the TFLG1 right away, but it didn't help.
 
lol, yes, I have already made and corrected the TOF error.
 
The TIOS is set to all zeros for input capture, TSCR1 is set to 80, TSCR2 is set to 07, and TCTL3/4 are set to zero.
 
 
 
Yes, the stack getting jumbled seems to be the problem. There is obviously some type of JSR that is executed behind the scenes (when the interrupt occurs), that does the pushing onto the stack, and then the rti pops them off....
 
 
Is there anyway to view/modify the code that runs the JSR internal to the mc9s12?
 
Thanks again for the help.
 
 



To: [hidden email]
From: [hidden email]
Date: Wed, 20 Jul 2011 16:14:28 +0000
Subject: [68HC12] Re: Not returning from Interrupt (Figure this one out!)


 



I am not familiar with assembly in 'C' - I code strictly in assembly, but is the "ldd 0x05" correct? TC0 is at '0050', I interpret your line as '0005' based on your "staa 0x4e" line which is 004E which is correct for TFLG1. reading 'D' from 0005 will get you the low word of TCNT and TSCR1. but that's not really your issue here...

you may want to try to clear the TFGL1 right away - it will not cause another interrupt since CCR-I is still set until the RTI.

are you aware of the TOF flag in TFLG2? Make sure your ISR is in the right spot and not pointed to by the TOF vector - speaking from experience here :)

what is your timer configuration? What values to you set for TIOS, TSCR1/2, TCTL3/4

I'm not sure why your stack is getting jumbled. I've never seen that...

--- In [hidden email], Jerry Fields <electronic_tech1@...> wrote:

>
>
> Thanks for the info on the un-needed sei. I removed it, but it didn't help. I do not call cli or sei anywhere else btw.
>
> Here is my ISR code.
>
>
> void tc1_isr(void)
> {
>
> asm("sei");
> asm("ldd 0x05"); // Loading D with the input capture value of TC0
> asm("std 0x3400"); // Storing D in RAM @ address 3400
> asm("ldaa #0x01");
> asm("staa 0x4e"); //Clearing TFLG1, because an interrupt has occured
> asm("rti");
> }
>
>
> Is it normal for the registers to get pushed onto the stack in the wrong order? Or like in the case of register D, have its contents reversed? And then when I do the rti, it pops them off in the wrong order too. i.e. Y ending up with the contents of X after the pop.
>
> Thanks again for your help BTW.
>
>
>
>
> To: [hidden email]
> From: mikeg@...
> Date: Wed, 20 Jul 2011 15:15:51 +0000
> Subject: [68HC12] Re: Not returning from Interrupt (Figure this one out!)
>
>
>
>
>
>
> Can you post the source code? Or at least the ISR? Difficult to say what may be going on in the ISR. here are a couple of things to check if you haven't already done so:
>
> 1. Remove the SEI instruction in your ISR. The CCR 'I' flag automatically gets set when an interrupt occurs and does not get cleared by the MCU until the RTI instruction, so no other interrupts are possible unless you specifically do a CLI inside the ISR (be very careful when doing so - infinite ISR calls possible)
> 2. Make sure you are clearing the TFLG1 bit correctly - most flags require a write with '1' to clear them and an additional data register read to complete the clear
> 3. Do you do a CLI anywhere? You shouldn't need to.
> 4. My favorite mistake is to overwrite the stack with variables...
>
> Hope any of this helps. If not post your ISR and I'll look at that.
> Mike
>
> --- In [hidden email], Jerry Fields <electronic_tech1@> wrote:
> >
> >
> > OK friends, I never solved the problem below. I ended up walking away from it out of frustration. OK, I am trying trying again! In my email below, I may have been incorrect in saying that the PC is not getting pushed onto the stack.....
> >
> > Present day problem:
> >
> > I am using the ECT (this time) on a mc9s12. I am doing an input capture on CH01, and everything is fine there. The program is running through an infinite loop, but when a wave form is detected for input capture, an interrupt occurs, and it branches off to the ISR. Again, so far so good.
> >
> > After I get to the ISR, I am doing an immediate sei to prevent any additional interrupts, and after its done doing its work, I am clearing the ECT interrupt flag, TFLG1 bit 0. Please correct any of the above if need be, but I don't think the problem has anything to do with what flags im clearing or not clearing.
> >
> >
> > The problem I believe, is how the registers are being pushed onto, and then pulled off of the stack during the attempted return from the ISR. OK, while I'm in the infinite (do nothing) for loop, the registers read as followed:
> >
> > PC: C097
> > SP: 3DFA
> > X: 080A
> > Y 0800
> > D: 0700
> > CCR: 0000
> >
> >
> > As soon as the interrupt occurs, and it jumps to the ISR, it pushes the registers onto the stack as follows, (I viewed this in a "data window" that the Development environment provides):
> >
> > After the jump to the ISR, all the registers are the same except for the PC and SP. The SP now has 3DEF. 3DFA - 3DEF = B
> >
> > So it looks like the stack had 11 bytes pushed onto it. I would expect 10 or 12 depending on weather the CCR gets pushed onto it or not. Not sure why it moved 11. ??
> >
> > Viewing the stack in memory, it now looks like this:
> >
> >
> >
> > Starting at 3DEF, and going up:
> >
> > 3D FA 00 00 07 08 0A 08 00 C0 97 If I line these memory locations up with the orginal register values, it looks like this:
> >
> >
> > PC: C097 C097
> > SP: 3DFA 0800
> > X: 080A 080A
> > Y 0800 0007
> > D: 0700 FA00
> > CCR: 0000 3D
> >
> > As you can see, the values don't line up, and the D register's value has even been reversed.
> >
> >
> > After the ISR is finished, I execute a RTI, and this is what is popped off of the stack into the registers:
> >
> >
> > PC: 0800
> > SP: 3DF8
> > X: 0007
> > Y 080A
> > D: 00FA
> > CCR: 003D
> >
> > No only did it push the values onto the stack incorrectly, but it pulled it off incorrectly also. I was tracing through the program, and while it was in the ISR, I manually replaced the 08 00 value on the stack with C0 97, (the proper return address), and when it got to the RTI, it properly jumped back to the infinite loop.
> >
> >
> > HELP!
> >
> > Any Ideas?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > To: [hidden email]
> > From: karpicz@
> > Date: Thu, 20 Jan 2011 19:44:51 +0200
> > Subject: Re: [68HC12] Not returning from Interrupt
> >
> >
> > Failure to clear interrupt flag is #1 for not returning from interrupt. 2nd
> > is wrong return from ISR instruction (should be RTI, and not RTS or RTC),
> > but in this case program will crash soon and BDM debugger should tell you
> > something about this.
> > So what is the setting of AFFC bit and how are you clearing ATD interrupt
> > flag?
> >
> > Edward
> >
> > ----- Original Message -----
> > From: "Jerry Fields" <electronic_tech1@>
> > To: <[hidden email]>
> > Sent: Thursday, January 20, 2011 6:42 PM
> > Subject: [68HC12] Not returning from Interrupt
> >
> > >
> > >
> > >
> > >
> > >
> > > Hello,
> > >
> > > I do not have my source code with me to post, however, I was hoping
> > > someone can help me with a quick tip, or something I might be over
> > > looking.
> > >
> > > I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
> > > am new to using interrupts(to a degree), so please bare with me. I am
> > > running through an infinite loop in my software, but during that loop, I
> > > enable the ATD interrupt. A short time after the ATD interrupt is enabled,
> > > it branches off properly, (I believe after it finishes a conversion), and
> > > executes the ATD interrupt routine I have wrote, (So far, so good).
> > >
> > > After the ATD interrupt is serviced, however, it does not return back to
> > > the infinite loop. I have traced it through, and I noticed that the
> > > Program Counter is NOT getting pushed onto the stack right before the
> > > leaves the infinite loop to service the interrupt.
> > >
> > > Does anyone (based on the information above) have any idea why the PC is
> > > NOT getting pushed onto the stack right before it leaves to service the
> > > interrupt?
> > >
> > > Thanks in advance for any help.
> > > Jerry
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>




     

[Non-text portions of this message have been removed]



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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/68HC12/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/68HC12/join
    (Yahoo! ID required)

<*> To change settings via email:
    [hidden email]
    [hidden email]

<*> To unsubscribe from this group, send an email to:
    [hidden email]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply | Threaded
Open this post in threaded view
|

Re: Not returning from Interrupt (Figure this one out!)

Michael-465
hmmmmmmm ... this one's a head-scratcher.  looks like all the settings are correct.

So what actually happens when you run the code?  You say it gets to the ISR ok, but when it returns it just goes off into la-la land due to the stack mis-alignment?  Do you have single-step capability with your IDE?  Where does the code want to go to after the RTI?

Here's a thought - crude but maybe worth a try. Can you re-arrange the stack by popping off and pushing back the data in the correct order?  seems crazy, but maybe in the process you might uncover a previously undiscovered issue...  I'm grapsing at straws here, sorry.

--- In [hidden email], Jerry Fields <electronic_tech1@...> wrote:

>
>
> Yes, sorry about that, the '05' was a typo. It should have been '50'.
>  
> OK, cleared the TFLG1 right away, but it didn't help.
>  
> lol, yes, I have already made and corrected the TOF error.
>  
> The TIOS is set to all zeros for input capture, TSCR1 is set to 80, TSCR2 is set to 07, and TCTL3/4 are set to zero.
>  
>  
>  
> Yes, the stack getting jumbled seems to be the problem. There is obviously some type of JSR that is executed behind the scenes (when the interrupt occurs), that does the pushing onto the stack, and then the rti pops them off....
>  
>  
> Is there anyway to view/modify the code that runs the JSR internal to the mc9s12?
>  
> Thanks again for the help.
>  
>  
>
>
>
> To: [hidden email]
> From: mikeg@...
> Date: Wed, 20 Jul 2011 16:14:28 +0000
> Subject: [68HC12] Re: Not returning from Interrupt (Figure this one out!)
>
>
>  
>
>
>
> I am not familiar with assembly in 'C' - I code strictly in assembly, but is the "ldd 0x05" correct? TC0 is at '0050', I interpret your line as '0005' based on your "staa 0x4e" line which is 004E which is correct for TFLG1. reading 'D' from 0005 will get you the low word of TCNT and TSCR1. but that's not really your issue here...
>
> you may want to try to clear the TFGL1 right away - it will not cause another interrupt since CCR-I is still set until the RTI.
>
> are you aware of the TOF flag in TFLG2? Make sure your ISR is in the right spot and not pointed to by the TOF vector - speaking from experience here :)
>
> what is your timer configuration? What values to you set for TIOS, TSCR1/2, TCTL3/4
>
> I'm not sure why your stack is getting jumbled. I've never seen that...
>
> --- In [hidden email], Jerry Fields <electronic_tech1@> wrote:
> >
> >
> > Thanks for the info on the un-needed sei. I removed it, but it didn't help. I do not call cli or sei anywhere else btw.
> >
> > Here is my ISR code.
> >
> >
> > void tc1_isr(void)
> > {
> >
> > asm("sei");
> > asm("ldd 0x05"); // Loading D with the input capture value of TC0
> > asm("std 0x3400"); // Storing D in RAM @ address 3400
> > asm("ldaa #0x01");
> > asm("staa 0x4e"); //Clearing TFLG1, because an interrupt has occured
> > asm("rti");
> > }
> >
> >
> > Is it normal for the registers to get pushed onto the stack in the wrong order? Or like in the case of register D, have its contents reversed? And then when I do the rti, it pops them off in the wrong order too. i.e. Y ending up with the contents of X after the pop.
> >
> > Thanks again for your help BTW.
> >
> >
> >
> >
> > To: [hidden email]
> > From: mikeg@
> > Date: Wed, 20 Jul 2011 15:15:51 +0000
> > Subject: [68HC12] Re: Not returning from Interrupt (Figure this one out!)
> >
> >
> >
> >
> >
> >
> > Can you post the source code? Or at least the ISR? Difficult to say what may be going on in the ISR. here are a couple of things to check if you haven't already done so:
> >
> > 1. Remove the SEI instruction in your ISR. The CCR 'I' flag automatically gets set when an interrupt occurs and does not get cleared by the MCU until the RTI instruction, so no other interrupts are possible unless you specifically do a CLI inside the ISR (be very careful when doing so - infinite ISR calls possible)
> > 2. Make sure you are clearing the TFLG1 bit correctly - most flags require a write with '1' to clear them and an additional data register read to complete the clear
> > 3. Do you do a CLI anywhere? You shouldn't need to.
> > 4. My favorite mistake is to overwrite the stack with variables...
> >
> > Hope any of this helps. If not post your ISR and I'll look at that.
> > Mike
> >
> > --- In [hidden email], Jerry Fields <electronic_tech1@> wrote:
> > >
> > >
> > > OK friends, I never solved the problem below. I ended up walking away from it out of frustration. OK, I am trying trying again! In my email below, I may have been incorrect in saying that the PC is not getting pushed onto the stack.....
> > >
> > > Present day problem:
> > >
> > > I am using the ECT (this time) on a mc9s12. I am doing an input capture on CH01, and everything is fine there. The program is running through an infinite loop, but when a wave form is detected for input capture, an interrupt occurs, and it branches off to the ISR. Again, so far so good.
> > >
> > > After I get to the ISR, I am doing an immediate sei to prevent any additional interrupts, and after its done doing its work, I am clearing the ECT interrupt flag, TFLG1 bit 0. Please correct any of the above if need be, but I don't think the problem has anything to do with what flags im clearing or not clearing.
> > >
> > >
> > > The problem I believe, is how the registers are being pushed onto, and then pulled off of the stack during the attempted return from the ISR. OK, while I'm in the infinite (do nothing) for loop, the registers read as followed:
> > >
> > > PC: C097
> > > SP: 3DFA
> > > X: 080A
> > > Y 0800
> > > D: 0700
> > > CCR: 0000
> > >
> > >
> > > As soon as the interrupt occurs, and it jumps to the ISR, it pushes the registers onto the stack as follows, (I viewed this in a "data window" that the Development environment provides):
> > >
> > > After the jump to the ISR, all the registers are the same except for the PC and SP. The SP now has 3DEF. 3DFA - 3DEF = B
> > >
> > > So it looks like the stack had 11 bytes pushed onto it. I would expect 10 or 12 depending on weather the CCR gets pushed onto it or not. Not sure why it moved 11. ??
> > >
> > > Viewing the stack in memory, it now looks like this:
> > >
> > >
> > >
> > > Starting at 3DEF, and going up:
> > >
> > > 3D FA 00 00 07 08 0A 08 00 C0 97 If I line these memory locations up with the orginal register values, it looks like this:
> > >
> > >
> > > PC: C097 C097
> > > SP: 3DFA 0800
> > > X: 080A 080A
> > > Y 0800 0007
> > > D: 0700 FA00
> > > CCR: 0000 3D
> > >
> > > As you can see, the values don't line up, and the D register's value has even been reversed.
> > >
> > >
> > > After the ISR is finished, I execute a RTI, and this is what is popped off of the stack into the registers:
> > >
> > >
> > > PC: 0800
> > > SP: 3DF8
> > > X: 0007
> > > Y 080A
> > > D: 00FA
> > > CCR: 003D
> > >
> > > No only did it push the values onto the stack incorrectly, but it pulled it off incorrectly also. I was tracing through the program, and while it was in the ISR, I manually replaced the 08 00 value on the stack with C0 97, (the proper return address), and when it got to the RTI, it properly jumped back to the infinite loop.
> > >
> > >
> > > HELP!
> > >
> > > Any Ideas?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > To: [hidden email]
> > > From: karpicz@
> > > Date: Thu, 20 Jan 2011 19:44:51 +0200
> > > Subject: Re: [68HC12] Not returning from Interrupt
> > >
> > >
> > > Failure to clear interrupt flag is #1 for not returning from interrupt. 2nd
> > > is wrong return from ISR instruction (should be RTI, and not RTS or RTC),
> > > but in this case program will crash soon and BDM debugger should tell you
> > > something about this.
> > > So what is the setting of AFFC bit and how are you clearing ATD interrupt
> > > flag?
> > >
> > > Edward
> > >
> > > ----- Original Message -----
> > > From: "Jerry Fields" <electronic_tech1@>
> > > To: <[hidden email]>
> > > Sent: Thursday, January 20, 2011 6:42 PM
> > > Subject: [68HC12] Not returning from Interrupt
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hello,
> > > >
> > > > I do not have my source code with me to post, however, I was hoping
> > > > someone can help me with a quick tip, or something I might be over
> > > > looking.
> > > >
> > > > I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
> > > > am new to using interrupts(to a degree), so please bare with me. I am
> > > > running through an infinite loop in my software, but during that loop, I
> > > > enable the ATD interrupt. A short time after the ATD interrupt is enabled,
> > > > it branches off properly, (I believe after it finishes a conversion), and
> > > > executes the ATD interrupt routine I have wrote, (So far, so good).
> > > >
> > > > After the ATD interrupt is serviced, however, it does not return back to
> > > > the infinite loop. I have traced it through, and I noticed that the
> > > > Program Counter is NOT getting pushed onto the stack right before the
> > > > leaves the infinite loop to service the interrupt.
> > > >
> > > > Does anyone (based on the information above) have any idea why the PC is
> > > > NOT getting pushed onto the stack right before it leaves to service the
> > > > interrupt?
> > > >
> > > > Thanks in advance for any help.
> > > > Jerry
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > > >
> > > >
> > > > ------------------------------------
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>      
>
> [Non-text portions of this message have been removed]
>


Reply | Threaded
Open this post in threaded view
|

Re: Not returning from Interrupt (Figure this one out!)

dheisswolf
In reply to this post by Jerry Fields


Why don't you post the assember listing (or at least the s-record) of your compliled ISR code?

The stack frame you've posted looks ok, except for the additional word:

        |<-----correct stack frame-------->|
 3D  FA  00  00  07  08  0A  08  00  C0  97
|<---->|
pushed by software

If you don't clear the I-bit, then the instruction which pushes the extra word ($3DFA) onto the stack must be somewhere in your ISR.


--- In [hidden email], Jerry Fields <electronic_tech1@...> wrote:

>
>
> OK friends, I never solved the problem below. I ended up walking away from it out of frustration. OK, I am trying trying again! In my email below, I may have been incorrect in saying that the PC is not getting pushed onto the stack.....
>  
>  Present day problem:
>  
> I am using the ECT (this time) on a mc9s12. I am doing an input capture on CH01, and everything is fine there. The program is running through an infinite loop, but when a wave form is detected for input capture, an interrupt occurs, and it branches off to the ISR. Again, so far so good.
>  
> After I get to the ISR, I am doing an immediate sei to prevent any additional interrupts, and after its done doing its work, I am clearing the ECT interrupt flag, TFLG1 bit 0. Please correct any of the above if need be, but I don't think the problem has anything to do with what flags im clearing or not clearing.
>  
>  
> The problem I believe, is how the registers are being pushed onto, and then pulled off of the stack during the attempted return from the ISR. OK, while I'm in the infinite (do nothing) for loop, the registers read as followed:
>  
> PC:   C097
> SP:   3DFA
> X:     080A
> Y      0800
> D:     0700
> CCR: 0000
>  
>  
> As soon as the interrupt occurs, and it jumps to the ISR, it pushes the registers onto the stack as follows, (I viewed this in a "data window" that the Development environment provides):
>  
> After the jump to the ISR, all the registers are the same except for the PC and SP. The SP now has 3DEF.   3DFA - 3DEF = B
>  
> So it looks like the stack had 11 bytes pushed onto it. I would expect 10 or 12 depending on weather the CCR gets pushed onto it or not. Not sure why it moved 11.  ??
>  
> Viewing the stack in memory, it now looks like this:
>  
>  
>  
> Starting at 3DEF, and going up:
>  
> 3D  FA  00  00  07  08  0A  08  00  C0  97  If I line these memory locations up with the orginal register values, it looks like this:
>  
>  
> PC:   C097       C097
> SP:   3DFA       0800
> X:     080A       080A
> Y      0800       0007
> D:     0700      FA00
> CCR: 0000         3D
>  
> As you can see, the values don't line up, and the D register's value has even been reversed.
>  
>  
> After the ISR is finished, I execute a RTI, and this is what is popped off of the stack into the registers:
>  
>  
> PC:   0800
> SP:   3DF8
> X:     0007
> Y      080A
> D:     00FA
> CCR: 003D
>  
> No only did it push the values onto the stack incorrectly, but it pulled it off incorrectly also. I was tracing through the program, and while it was in the ISR, I manually replaced the 08 00 value on the stack with C0 97, (the proper return address), and when it got to the RTI, it properly jumped back to the infinite loop.
>  
>  
> HELP!
>  
> Any Ideas?
>  
>  
>  
>  
>  
>
>  
>
>
>
> To: [hidden email]
> From: karpicz@...
> Date: Thu, 20 Jan 2011 19:44:51 +0200
> Subject: Re: [68HC12] Not returning from Interrupt
>
>  
> Failure to clear interrupt flag is #1 for not returning from interrupt. 2nd
> is wrong return from ISR instruction (should be RTI, and not RTS or RTC),
> but in this case program will crash soon and BDM debugger should tell you
> something about this.
> So what is the setting of AFFC bit and how are you clearing ATD interrupt
> flag?
>
> Edward
>
> ----- Original Message -----
> From: "Jerry Fields" <electronic_tech1@...>
> To: <[hidden email]>
> Sent: Thursday, January 20, 2011 6:42 PM
> Subject: [68HC12] Not returning from Interrupt
>
> >
> >
> >
> >
> >
> > Hello,
> >
> > I do not have my source code with me to post, however, I was hoping
> > someone can help me with a quick tip, or something I might be over
> > looking.
> >
> > I am using a MC9S12DP512 microcontroller on a Axiom CMD-12DP512 board. I
> > am new to using interrupts(to a degree), so please bare with me. I am
> > running through an infinite loop in my software, but during that loop, I
> > enable the ATD interrupt. A short time after the ATD interrupt is enabled,
> > it branches off properly, (I believe after it finishes a conversion), and
> > executes the ATD interrupt routine I have wrote, (So far, so good).
> >
> > After the ATD interrupt is serviced, however, it does not return back to
> > the infinite loop. I have traced it through, and I noticed that the
> > Program Counter is NOT getting pushed onto the stack right before the
> > leaves the infinite loop to service the interrupt.
> >
> > Does anyone (based on the information above) have any idea why the PC is
> > NOT getting pushed onto the stack right before it leaves to service the
> > interrupt?
> >
> > Thanks in advance for any help.
> > Jerry
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>      
>
> [Non-text portions of this message have been removed]
>


12