[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Simulating with AVR-Studio

From: Jim Pearce
Subject: Re: [avr-gcc-list] Simulating with AVR-Studio
Date: Mon, 26 Mar 2001 08:16:19 -0500

I sent a comment on this problem to the AvrX mail list.  I just checked and it 
hasn't made it to the archive yet so I'll repeat it

I mentioned in the avr-gcc list some time ago a problem that AVR studio 
sometimes does not show the disassembly that corresponds to
the current IP.  This is almost always the case with the main() when using AvrX.

This kept bothering me so I dove into it to find out why.  I now know what 
causes the problem and it appears to be a bug in AVR
Studio though there is a workaround.


The .obj file contains 9 byte records for every program memory word:

aa aa aa op op ff LL LL MM

aa = 24 bits of address
op = 16 bits of op code
ff = Source file number (there is a list of files at the end of the obj file)
LL = 16 bits of line number within that source file
MM = flag to indicate op code is a macro

The problem occurs when there is an op code in the AVR .obj file that is 
flagged as a macro and points to a different source file
from the one that holds the source for the module.

An example from main():
00 00 87 CF D8 00 00 3E 00  -->  0087  rjmp .L19  Source file 0, Line 3e, not a 
00 00 88 C4 96 05 00 F3 01 --> 0088 rjmp _Epilog Source file 5, line F3, Is a 
00 00 89 E0 80 00 00 5F 00 --> 0089 ldi r24,lo8(0) Source file 0, line 5f, not 
a macro

The presence of the macro line kills Studio's brains!

I fixed the problem by creating a #define instead of an inline for Epilog();  
This seems to work!


To sum up:  Don't use macros! AVR Studio dosen't like them.

If this is not your problem maybe you can use this a  starting point for 
looking at a hex dump of your .obj file.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]