AVR-Chat

I'm working up what should be a fairly simple Xmodem bootloader.

I've hit some really WIERD problems in execution in a real chip, and 
I thought I'd step back to sim, to see what's going on.

In sim, I get to a point in the code, VERY close to where the real 
app in a chip has problems.. (hmmmm) and the sim complains 
of "illegal opcode $FFFF at location $FF87 (or similar, depends on 
the build)
If I load the lst file, the instruction there is NOT $FFFF, it is a 
perfectly valid return.

The really spooky thing is that as close as I can tell, this is the 
same point that the real app has problems at. 

Is there something wierd about using the last page or so of codespace?
My bootloader orgs to $FE00 and is all done by $FFE6, even with 
debugging support that is almost as big as the bootloader itself.

I could re-org lower, I have ooooodles of space, but that's 
a "voodoo" approach to fixing the problem.

Loaded into a chip, the app gives me wierd problems that shift as I 
include and remove debugging code, as if there was a flag or stack 
problem, but myself, and another experienced SW guy have been over it 
and we didn't catch anything significant.

I'm sending messages on the second serial port to debug, and I am 
using/preserving ELPM during those routines.  Stack pointer IS 
initted, and I'm only using ram up to $0185, with SP at $10FF

00ff80 9350 0102 	sts			XmodemBlk,Expseq
	;	
00ff82 ef0f      	ldi			TEMP,$FF	
		;
00ff83 1b05      	sub			TEMP,Expseq	
		;	
00ff84 9300 0103 	sts			XmodemBlk+1,TEMP
	;
;Above here, I'm faking in a 'received packet' so I can sim through
;verification and programming into the program memory.

00ff86 dedb      	rcall		Get_Packet_Verify	;
00ff87 9508      	ret <--- Here's where it says there's an 
$FFFF opcode..

SP at this moment is $10FD, and will be $10FF if this return would 
actually return...  In sim, the execution drops into some send 
message from rom routines and this behaviour is very very similar to 
what's happening in the real chip.

--- In AVR-Chat@yahoogroups.com, "Dave VanHorn" <microbrix@...> wrote:
> In sim, I get to a point in the code, VERY close to where the real 
> app in a chip has problems.. (hmmmm) and the sim complains 
> of "illegal opcode $FFFF at location $FF87 (or similar, depends on 
> the build).

You may be seeing effects of the differences between the RWW and NRWW 
sections of Flash.  Depending the the size of the bootloader section, 
some of the NRWW Flash will be in the application section.  The 
bootloder itself is always completely in the NRWW section.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

Reorged it to $F000, still has the same problems.

> You may be seeing effects of the differences between the RWW and NRWW
> sections of Flash.  Depending the the size of the bootloader section,
> some of the NRWW Flash will be in the application section.  The
> bootloder itself is always completely in the NRWW section.

Possible, but I THINK I'm re-enabling it.
The effects are pretty bizarre, what ever it is.

> Possible, but I THINK I'm re-enabling it.
> The effects are pretty bizarre, what ever it is.

Thinking on that further..

Ok, the sim AND the chip are acting "nuts" in a way that suggests that
sort of problem, but would they try to accurately simulate executing
out of unreadable rom?
I'd think throwing a serious error flag would be more appropriate!

Here's page write:  Erase is similar

Loader_Page_Write:
	rcall	SPM_Ready	;
	rcall	Loader_MakePage	;

	ldi	TEMP,$05		;PGWRT and SPMEN
	sts	SPMCSR,TEMP	;
	spm	                                        ; Flash page write
	nop
	rcall	Enable_RWW
	ret
;
;****************************
;
Enable_RWW:

	rcall 	SPM_Ready
	clr	TEMP
	sbr 	TEMP, (1<<RWWSRE) | (1<<SPMEN)
	sts 	SPMCR, TEMP			
	spm
	ret
;
;******************************
;
; Wait till the SPM and EEprom writes are done
;
SPM_Ready:
	lds	TEMP,SPMCSR
	andi 	TEMP,(1<<SPMEN)
	brne 	SPM_Ready			

Wait_ee:
	sbic 	EECR, EEWE
	rjmp 	Wait_ee	
	ret
;

Hi Dave,

> Loaded into a chip, the app gives me wierd problems that shift as I
> include and remove debugging code, as if there was a flag or stack
> problem, but myself, and another experienced SW guy have been over it
> and we didn't catch anything significant.

This is typically symptomatic of using uninitialized variables (in C -
in assembler it would correspond to uninitialized registers).

There's also the whole byte/word difference problem . (i.e. you're not
trying to erase the area that the bootloader is in when you really
think you're only around the 64k mark).

XModem would be sending bytes, but you're going to be programming words.

> I'm sending messages on the second serial port to debug, and I am
> using/preserving ELPM during those routines.  Stack pointer IS
> initted, and I'm only using ram up to $0185, with SP at $10FF
>
> 00ff80 9350 0102        sts                     XmodemBlk,Expseq
>        ;
> 00ff82 ef0f             ldi                     TEMP,$FF
>                ;
> 00ff83 1b05             sub                     TEMP,Expseq
>                ;
> 00ff84 9300 0103        sts                     XmodemBlk+1,TEMP
>        ;
> ;Above here, I'm faking in a 'received packet' so I can sim through
> ;verification and programming into the program memory.
>
> 00ff86 dedb             rcall           Get_Packet_Verify       ;
> 00ff87 9508             ret <--- Here's where it says there's an
> $FFFF opcode..
>
> SP at this moment is $10FD, and will be $10FF if this return would
> actually return...  In sim, the execution drops into some send
> message from rom routines and this behaviour is very very similar to
> what's happening in the real chip.
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

> This is typically symptomatic of using uninitialized variables (in C -
> in assembler it would correspond to uninitialized registers).

Yup, or stack pointer corruption, or a jump out of a routine due to
copy and paste problems, (jumping into the old routine instead of
within the new one)

> There's also the whole byte/word difference problem . (i.e. you're not
> trying to erase the area that the bootloader is in when you really
> think you're only around the 64k mark).

Actually, one of the first things the code does, is set the protection bits.
And I'm sending out on a diag pin, the RAMPZ and Z registers while I'm
writing, and they are always sane.  $000000 through $01FD80 . The "80"
is because I would have just finished writing the second packet into
the spm buffer, and I started the write with the pointer there.

I know I need words, not bytes.

Anyone want to have a look at this?
I have it wrapped up in a very small and (hopefully) well commented package.

At this point, I think I have everything working, except that the data
is NOT getting written in the real chip, but IS getting written in the
sim.

Other than that one little thing.. :)  It seems to be working.

On Tuesday 17 July 2007 21:13, Dave Hylands wrote:

> This is typically symptomatic of using uninitialized variables (in C -
> in assembler it would correspond to uninitialized registers).

Try http://www.splint.org for finding such problems.


-- 
                http://www.wearablesmartsensors.com/
 http://www.softwaresafety.net/ http://www.designer-iii.com/
                 http://www.unusualresearch.com/