AVR-Chat

Starting off on another crash project.. 
Downloaded the latest studio.

File assembles ok, no warnings or errors, but whenever I do a call or
rcall off the main loop, I get "invalid opcode 0xFFFF at address 0x00f020 

The address is always the same!

I looked at the lst file, and the code looks normal.
The call it's having problems with is: 0001A2 d087

Stack IS set up, and hasn't been corrupted.
I can add another call in front of this one, and I get the same problem.

Very odd.

Anyone seen this, or have ideas?

At 06:42 AM 17/06/2007, you wrote:
>I get "invalid opcode 0xFFFF at address 0x00f020
>The address is always the same!

What is PHYSICALLY there? Have you loaded the code into the simulator
or used other debugging tools to have a look at that location?

Included the wrong interrupt vectors (SOMEONE did this a while ago)?
No memory at 0x00f020? Which chip are you using?

You do know that it will be something silly and you will kick
yourself when you find it :-)

A few days ago I spend about half an hour trying to figure out
why my Dragon was acting funny, I could not read porta no matter
what I did....well it turned out that I had changed debugging
mode from Dragon to simulator and what I was looking was not
the physical port at all.... :-[

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.17/850 - Release Date: 15/06/2007 11:31 AM

> What is PHYSICALLY there? Have you loaded the code into the simulator
> or used other debugging tools to have a look at that location?

Yup, in the sim, $FFFF is what's at that location, but the RCALL isn't
calling that location.

> Included the wrong interrupt vectors (SOMEONE did this a while ago)?
> No memory at 0x00f020? Which chip are you using?

M128, it shouldn't be ANYWHERE near there though..
In the disasm, the call reads as rcall PC+0268
PC at this moment is 00001B5, so that should call   0041D
Reading the .lst file, the routine I want is conveinently located at 0041D
so I single step, and...

I'm at 0000F020 with an opcode of $FFFF



> You do know that it will be something silly and you will kick
> yourself when you find it :-)

Yeah.. I'm taking yoga now, so I'm getting better at that.

> A few days ago I spend about half an hour trying to figure out
> why my Dragon was acting funny, I could not read porta no matter
> what I did....well it turned out that I had changed debugging
> mode from Dragon to simulator and what I was looking was not
> the physical port at all.... :-[

Yup, that happens.
And it's probably something like that, since this is a new install,
and "cold start" of a project.

Dave and John,

I'm developing an automatic ass kicking machine right now, to be used 
when I do something that's really dumb.  The first copy is mine.  Shall 
I sign you up for one?

The biggest problem to date has been finding a size 11EEE combat boot 
like my Drill Instructor in Bootcamp had.


REB



David VanHorn wrote:

>>What is PHYSICALLY there? Have you loaded the code into the simulator
>>or used other debugging tools to have a look at that location?
>>    
>>
>
>Yup, in the sim, $FFFF is what's at that location, but the RCALL isn't
>calling that location.
>
>  
>
>>Included the wrong interrupt vectors (SOMEONE did this a while ago)?
>>No memory at 0x00f020? Which chip are you using?
>>    
>>
>
>M128, it shouldn't be ANYWHERE near there though..
>In the disasm, the call reads as rcall PC+0268
>PC at this moment is 00001B5, so that should call   0041D
>Reading the .lst file, the routine I want is conveinently located at 0041D
>so I single step, and...
>
>I'm at 0000F020 with an opcode of $FFFF
>
>
>
>  
>
>>You do know that it will be something silly and you will kick
>>yourself when you find it :-)
>>    
>>
>
>Yeah.. I'm taking yoga now, so I'm getting better at that.
>
>  
>
>>A few days ago I spend about half an hour trying to figure out
>>why my Dragon was acting funny, I could not read porta no matter
>>what I did....well it turned out that I had changed debugging
>>mode from Dragon to simulator and what I was looking was not
>>the physical port at all.... :-[
>>    
>>
>
>Yup, that happens.
>And it's probably something like that, since this is a new install,
>and "cold start" of a project.
>  
>

At 08:25 AM 17/06/2007, you wrote:
>I'm developing an automatic ass kicking machine right now,
>I sign you up for one?

Yes please!! I have put a hole in the brick wall where I keep on
banging my head every time I mess up :-D

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.17/850 - Release Date: 15/06/2007 11:31 AM

I've tracked it down, but still it makes no sense...

It's the SEI instruction!
That's the last thing I do before hitting the idle loop.

Any call I make AFTER the SEI, ends up in this wierd place.
That means that it's almost certainly an ISR that's vectored to the
wrong place, but it's not jumping to the interrupt vectors and THEN
off to somewhere else. What happens is that it would appear that the
call should be a normal call, but the address it lands on is wrong.

Consistent, but wrong.

Wierd.

ps:

even this workaround:

in  temp,sreg
ori  temp,$80
out  sreg,temp

causes the same problem!