Reply by Ulf Samuelsson●November 22, 20042004-11-22
>
> I used Atmega32(DIP) in my prototype board to test part of my source
> code, the execution is smooth. Then I ported the code to Atmega64,
> only little code modifications are required.
>
> However, I found the program counter quickly goes to an unknown
> address when the program runs in the beginning. I then trace the
> program using the debugger and find the program retrieve a wrong
> program counter after calling subroute, which finally brings the
> program to reset. Why this happens? Could anyone help me? The code
> segment is attached in the following. Thanks!
>
> int main(void)
> {
> unsigned char key,sc;
> unsigned char uc;
You don't show all the file: are you aware that the interrupt vector table
needs to
customized for each AVR chip. An interrupt vector can be at one address on
the mega32
and at another adress on the mega64. The effect is that anything can happen.
Do you initialize all unused interrupts to the "RETI" instruction?
--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.
Reply by terry●November 21, 20042004-11-21
"Leon Heller" <leon_heller@hotmail.com> wrote in message news:<41a07d68$0$10974$cc9e4d1f@news-text.dial.pipex.com>...
> "terry" <leonlai2k@yahoo.com> wrote in message
> news:9904d48.0411210316.392afca5@posting.google.com...
> > Hi,
> >
> > I used Atmega32(DIP) in my prototype board to test part of my source
> > code, the execution is smooth. Then I ported the code to Atmega64,
> > only little code modifications are required.
> >
> > However, I found the program counter quickly goes to an unknown
> > address when the program runs in the beginning. I then trace the
> > program using the debugger and find the program retrieve a wrong
> > program counter after calling subroute, which finally brings the
> > program to reset. Why this happens? Could anyone help me? The code
> > segment is attached in the following. Thanks!
>
> Have you checked the actual machine code against the assembler listing? It
> could be a bug in the compiler. I've known compilers (usually beta releases,
> but not always) generate the wrong code, in some circumstances. 8-(
>
> Leon
I have checked both the machine codes of CALL and RET instructions and
they are both correct.8-(
Reply by Gary Kato●November 21, 20042004-11-21
> if(interruptNum < TIMER_NUM_INTERRUPTS)
> {
> // set the interrupt function to run nothing
> TimerIntFunc[interruptNum] = 0;//<---------reset after running this
command
> }
Is the call to timerDetach that resets the one called from timerInit or is it a
later call?
Post your timer interrupt service routine. I assume it's checking if
TimerIntFunc[x] is 0 before jumping or calling the routine? I'm guessing that
you assign 0 to TimerIntFunc[x], a timer interrupt happens, and you jump to 0
(don't know if that's the reset address for AVR).
Reply by Tauno Voipio●November 21, 20042004-11-21
Leon Heller wrote:
> "terry" <leonlai2k@yahoo.com> wrote in message
> news:9904d48.0411210316.392afca5@posting.google.com...
>
>>Hi,
>>
>>I used Atmega32(DIP) in my prototype board to test part of my source
>>code, the execution is smooth. Then I ported the code to Atmega64,
>>only little code modifications are required.
>>
>>However, I found the program counter quickly goes to an unknown
>>address when the program runs in the beginning. I then trace the
>>program using the debugger and find the program retrieve a wrong
>>program counter after calling subroute, which finally brings the
>>program to reset. Why this happens? Could anyone help me? The code
>>segment is attached in the following. Thanks!
>
>
> Have you checked the actual machine code against the assembler listing? It
> could be a bug in the compiler. I've known compilers (usually beta releases,
> but not always) generate the wrong code, in some circumstances. 8-(
>
> Leon
The function stores a 16 bit zero in a location of the
vector. It can clobber the return address in the stack
if the array and/or the stack is improperly set up.
The code doubles the index input in r24 and subtracts
0xfde7 from it, effectively pointing to the location
0x219 + 2*index, and stores two bytes of zeroes in the
location pointed to and the next byte.
The compiler is not defined, but is seems to be GCC-AVR.
--
Tauno Voipio
tauno voipio (at) iki fi
Reply by Ben Jackson●November 21, 20042004-11-21
In article <9904d48.0411210316.392afca5@posting.google.com>,
terry <leonlai2k@yahoo.com> wrote:
>However, I found the program counter quickly goes to an unknown
>address when the program runs in the beginning.
Those are basically the last few instructions to execute. I'd guess there
is a bug in your interrupt handler. Even if it works correctly (in terms
of processing interrupts) it may trash the stack or otherwise fail to
preserve all of the necessary state to resume after it runs.
--
Ben Jackson
<ben@ben.com>
http://www.ben.com/
Reply by Leon Heller●November 21, 20042004-11-21
"terry" <leonlai2k@yahoo.com> wrote in message
news:9904d48.0411210316.392afca5@posting.google.com...
> Hi,
>
> I used Atmega32(DIP) in my prototype board to test part of my source
> code, the execution is smooth. Then I ported the code to Atmega64,
> only little code modifications are required.
>
> However, I found the program counter quickly goes to an unknown
> address when the program runs in the beginning. I then trace the
> program using the debugger and find the program retrieve a wrong
> program counter after calling subroute, which finally brings the
> program to reset. Why this happens? Could anyone help me? The code
> segment is attached in the following. Thanks!
Have you checked the actual machine code against the assembler listing? It
could be a bug in the compiler. I've known compilers (usually beta releases,
but not always) generate the wrong code, in some circumstances. 8-(
Leon
Reply by terry●November 21, 20042004-11-21
Hi,
I used Atmega32(DIP) in my prototype board to test part of my source
code, the execution is smooth. Then I ported the code to Atmega64,
only little code modifications are required.
However, I found the program counter quickly goes to an unknown
address when the program runs in the beginning. I then trace the
program using the debugger and find the program retrieve a wrong
program counter after calling subroute, which finally brings the
program to reset. Why this happens? Could anyone help me? The code
segment is attached in the following. Thanks!
int main(void)
{
unsigned char key,sc;
unsigned char uc;
timerInit();
:
:
timerAttach(TIMER0OVERFLOW_INT,&timer);
initKB();
:
:
}
void timerInit(void)
{
u08 intNum;
// detach all user functions from interrupts
for(intNum=0; intNum<TIMER_NUM_INTERRUPTS; intNum++)
timerDetach(intNum);
// initialize all timers
timer0Init();
timer1Init();
#ifdef TCNT2 // support timer2 only if it exists
timer2Init();
#endif
// enable interrupts
sei();
}
void timerDetach(u08 interruptNum)
{
// make sure the interrupt number is within bounds
if(interruptNum < TIMER_NUM_INTERRUPTS)
{
// set the interrupt function to run nothing
TimerIntFunc[interruptNum] = 0;//<---------reset after running
this command
}
}
:
170: TimerIntFunc[interruptNum] = 0;
+00000D93: 2FE8 MOV R30,R24 Copy register
---- No Source ------------------------------------------------------------------------------------
+00000D94: 27FF CLR R31 Clear Register
+00000D95: 0FEE LSL R30 Logical Shift Left
+00000D96: 1FFF ROL R31 Rotate Left Through
Carry
+00000D97: 5EE7 SUBI R30,0xE7 Subtract immediate
+00000D98: 4FFD SBCI R31,0xFD Subtract immediate
with carry
+00000D99: 8210 STD Z+0,R1 Store indirect with
displacement
+00000D9A: 8211 STD Z+1,R1 Store indirect with
displacement
+00000D9B: 9508 RET Subroutine
return<-------Go to an unknown address
+00000D9C: 9508 RET Subroutine return
: