Pointer to memory location in Atmega128

hi good day,
           We are using  codevision AVR as compiler for atmega128 , and

bootloader(upper 2K) for loading application firmware(start from 0x0000

, size nearly 70K) and a separate data structure(start from 0xB400,
size nearly 20K). Now we want to access that data structure from our
application firmware.Actually we failed to access the upper 64k area by

declaring a pointer to that memory address.But we can access whatever
location which is below than 64K like as follow,


int flash *fp;


fp = 0x6800;
(this pointer point to 0x68 th page(104 th page), that means the actual

memory location is 0x3400)


what should we do to access the actual memory location 0xB400( that
means 360 th page (0x168 th page)).In atmega128 the address line is 16
bit. Can anybody point out me the correct direction to solve this
problem. thank you 


with regards 
marans

tamilmaranz@gmail.com wrote:
> hi good day,
>            We are using  codevision AVR as compiler for atmega128 , and
> 
> bootloader(upper 2K) for loading application firmware(start from 0x0000
> 
> , size nearly 70K) and a separate data structure(start from 0xB400,
> size nearly 20K). Now we want to access that data structure from our
> application firmware.Actually we failed to access the upper 64k area by
> 
> declaring a pointer to that memory address.But we can access whatever
> location which is below than 64K like as follow,
> 
> 
> int flash *fp;
> 
> 
> fp = 0x6800;
> (this pointer point to 0x68 th page(104 th page), that means the actual
> 
> memory location is 0x3400)
> 
> 
> what should we do to access the actual memory location 0xB400( that
> means 360 th page (0x168 th page)).In atmega128 the address line is 16
> bit. Can anybody point out me the correct direction to solve this
> problem. thank you 
> 
> 
> with regards 
> marans
> 

I suspect your problem lies in the use (somewhere buried deep in a 
macro) of the LPM instruction which only accesses the lower 64kB. you'll 
need to use the ELPM which avoids that restriction. Sorry I can't help 
more with the specifics - I don't know the Codevision tools.

"La" <lajunkjunk@talk21.com> schrieb im Newsbeitrag 
news:426613e5$0$94539$ed2619ec@ptn-nntp-reader01.plus.net...
> tamilmaranz@gmail.com wrote:
structure from our
>> application firmware.Actually we failed to access the upper 64k area by

What size (in bit) is your pointer variable? Typically it is 16 bit and does 
not hold the extra bit to address the upper 128k.

/Roland

On 19 Apr 2005 23:13:23 -0700, tamilmaranz@gmail.com wrote:

>hi good day,
>           We are using  codevision AVR as compiler for atmega128 , and
>
[...]
>int flash *fp;
>
>
>fp = 0x6800;
>(this pointer point to 0x68 th page(104 th page), that means the actual
>
>memory location is 0x3400)
>
>
>what should we do to access the actual memory location 0xB400( that
>means 360 th page (0x168 th page)).In atmega128 the address line is 16
>bit. Can anybody point out me the correct direction to solve this
>problem. thank you 

You can't do that in CodeVisionAVR.  It's a stated limitation of the
compiler that pointers to flash can only access the first 64k.

A new version of CodeVisionAVR is in development that _will_ allow
access to the upper 64k (and presumably upper 128k on the mega256, and
beyond on larger chips).  But it's not yet available AFAIK.  And any
such pointer will require more than two bytes of storage.

Until then, you'll have to drop into assembly.  CVAVR makes this
relatively painless.  Something like (WARNING: untested, probably
non-optimal code)

   unsigned int read_flash_word(unsigned int adr)
   {
      #asm
      ld   r30,Y
      ldd  r31,Y+1
      clr  r0
      sbrc r31,7
      inc  r0
      out  RAMPZ,r0
      clc
      rol  r30
      rol  r31
      elpm r0,z+
      elpm r31,z
      mov  r30,r0
      #endasm
   }

   unsigned int fp;
   unsigned int result;

   fp = 0x6800;
   result = read_flash_word(fp);

   fp = 0xB400;
   result = read_flash_word(fp);

Please RTFM for more details.  Good luck,
     
                               -=Dave
-- 
Change is inevitable, progress is not.