ATMega2560 Full Flash Memory Access with "PROGMEM="

Go To Last Post
38 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear all,

 Maybe this topic old & might have solved earlier, but i am not getting simple way to keep data in the flash memory, Well my requirement is to store data in flash  from Address 0x10000 to 0x2FFFF and may be beyond.

My data table size is like that - 

 

Table1[2000]PROGMEM=
Table2[5000]PROGMEM=
Table3[10000]PROGMEM=
Table4[15000]PROGMEM=
Table5[540]PROGMEM=
Table6[159]PROGMEM=
Table7[6589]PROGMEM=
Table8[7200]PROGMEM=
Table9[5698]PROGMEM=
Table10[4587]PROGMEM=
Table11[8754]PROGMEM=
Table12[18000]PROGMEM=
Table13[19000]PROGMEM=
Table14[17000]PROGMEM=
Table15[6542]PROGMEM=
Table16[6000]PROGMEM=
Table17[5800]PROGMEM=
Table18[654]PROGMEM=
Table19[123]PROGMEM=
Table20[980]PROGMEM=

 

wheather this procesure is right / wrong

 

Please help me by suggesting if there are some code or the site where it has already been solved/suggested

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What are the types of the data in your tables? 

 

And to save us all having to do it what is the sum of all those dimensions ? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Data Type is char i.e byte.

Total Sum of data is 0x1FFFF

i.e 128 KB (minimum ) may be more.

Actually i am searching a universal code/ method to store & access the data.

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well PROGMEM or __flash is the way to do this but you'll have to ensure no one array straddles a 64K boundary

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear Clawson,

I have read your post "Compile Error "size of array ... too large" and it was in the year of 2008,

I am using AVR Studio 4.15 version & is there any latest solution posted in any thread.

I want to have a code/ solution wherein i can use and understand in very simple and convenient way.

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure what you are talking about. No one of your arrays is "too large". They are all small enough that they can be individually defined. As I say the only issue you face is RAMPZ handling at 64K boundaries so the arrays need to be placed not to straddle a boundary.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I want to use Flash memory like this way

0x00000 to 0x0FFFF  for code

0x10000 to 0x3FFFF  for keeping data in Flash .

 

So Data will stay beyond the boundery of 64k.

 

Just now i have tried the code as suggested in the post  "Compile Error "size of array ... too large" & the Error is comming like  - 

 Error: value of 108496 too large for field of 2 bytes at 110343"

 

 

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The default linker script will try to place .progmem right after .vectors so you won't achieve this using PROGMEM or __flash. So you need to assign each array in turn to __attribute__((section(".table1"))) etc. Then for each use -Wl,-section-start=.table1=0x12340 or whatever. But again don't allow any to straddle a 64K boundary. Then use pgm_get_far_address() to get the far address to pass to pgm_read_byte_far().

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How to configure "-Wl,-section-start=.table1=0x12340" in AVR Studio 4.15 version.

I don't want to  straddle a 64K boundary , Dedicatedly i want to keep my data starting from address 0x10000 or 0x20000 of Flash Memory.

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, finally I'm at a PC so can give you an answer better than can be achieve using a phone...

 

Here's an example....

#include <avr/io.h>

__attribute__((section(".tab1"))) uint8_t tab1[100] = { 1,2,3, 4 };
__attribute__((section(".tab2"))) uint8_t tab2[400] = { 8, 9, 10, 11, 12 };

int main(void) {
    
}
C:\SysGCC\avr\bin>avr-gcc -mmcu=atmega2560 -Wl,-section-start=.tab1=0x12340 -Wl,-section-start=.tab2=0x18BC0 -Os test.c
-o test.elf

C:\SysGCC\avr\bin>avr-objdump -s -j .text -j .tab1 -j .tab2 test.elf

test.elf:     file format elf32-avr

Contents of section .tab1:
 12340 01020304 00000000 00000000 00000000  ................
 12350 00000000 00000000 00000000 00000000  ................
 12360 00000000 00000000 00000000 00000000  ................
 12370 00000000 00000000 00000000 00000000  ................
 12380 00000000 00000000 00000000 00000000  ................
 12390 00000000 00000000 00000000 00000000  ................
 123a0 00000000                             ....
Contents of section .tab2:
 18bc0 08090a0b 0c000000 00000000 00000000  ................
 18bd0 00000000 00000000 00000000 00000000  ................
 18be0 00000000 00000000 00000000 00000000  ................
 18bf0 00000000 00000000 00000000 00000000  ................
 18c00 00000000 00000000 00000000 00000000  ................
 18c10 00000000 00000000 00000000 00000000  ................
 18c20 00000000 00000000 00000000 00000000  ................
 18c30 00000000 00000000 00000000 00000000  ................
 18c40 00000000 00000000 00000000 00000000  ................
 18c50 00000000 00000000 00000000 00000000  ................
 18c60 00000000 00000000 00000000 00000000  ................
 18c70 00000000 00000000 00000000 00000000  ................
 18c80 00000000 00000000 00000000 00000000  ................
 18c90 00000000 00000000 00000000 00000000  ................
 18ca0 00000000 00000000 00000000 00000000  ................
 18cb0 00000000 00000000 00000000 00000000  ................
 18cc0 00000000 00000000 00000000 00000000  ................
 18cd0 00000000 00000000 00000000 00000000  ................
 18ce0 00000000 00000000 00000000 00000000  ................
 18cf0 00000000 00000000 00000000 00000000  ................
 18d00 00000000 00000000 00000000 00000000  ................
 18d10 00000000 00000000 00000000 00000000  ................
 18d20 00000000 00000000 00000000 00000000  ................
 18d30 00000000 00000000 00000000 00000000  ................
 18d40 00000000 00000000 00000000 00000000  ................
Contents of section .text:
 0000 0c947200 0c947e00 0c947e00 0c947e00  ..r...~...~...~.
 0010 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 0020 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 0030 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 0040 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 0050 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 0060 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 0070 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 0080 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 0090 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 00a0 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 00b0 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 00c0 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 00d0 0c947e00 0c947e00 0c947e00 0c947e00  ..~...~...~...~.
 00e0 0c947e00 11241fbe cfefd1e2 debfcdbf  ..~..$..........
 00f0 00e00cbf 0e948000 0c948300 0c940000  ................
 0100 80e090e0 0895f894 ffcf               ..........

C:\SysGCC\avr\bin>

As you can see, right data in the right places.

 

BTW this means that when the .hex file is created using avr-objcopy either -R's have to be used to remove everything but these sections of -j's have to be used to include them. Something like:

C:\SysGCC\avr\bin>avr-objcopy -O ihex -j .text -j .tab1 -j .tab2 test.elf test.hex

C:\SysGCC\avr\bin>type test.hex
:100000000C9472000C947E000C947E000C947E0084
:100010000C947E000C947E000C947E000C947E0068
:100020000C947E000C947E000C947E000C947E0058
:100030000C947E000C947E000C947E000C947E0048
:100040000C947E000C947E000C947E000C947E0038
:100050000C947E000C947E000C947E000C947E0028
:100060000C947E000C947E000C947E000C947E0018
:100070000C947E000C947E000C947E000C947E0008
:100080000C947E000C947E000C947E000C947E00F8
:100090000C947E000C947E000C947E000C947E00E8
:1000A0000C947E000C947E000C947E000C947E00D8
:1000B0000C947E000C947E000C947E000C947E00C8
:1000C0000C947E000C947E000C947E000C947E00B8
:1000D0000C947E000C947E000C947E000C947E00A8
:1000E0000C947E0011241FBECFEFD1E2DEBFCDBF46
:1000F00000E00CBF0E9480000C9483000C94000070
:0A01000080E090E00895F894FFCF2E
:020000021000EC
:102340000102030400000000000000000000000083
:10235000000000000000000000000000000000007D
:10236000000000000000000000000000000000006D
:10237000000000000000000000000000000000005D
:10238000000000000000000000000000000000004D
:10239000000000000000000000000000000000003D
:0423A0000000000039
:108BC00008090A0B0C000000000000000000000073
:108BD0000000000000000000000000000000000095
:108BE0000000000000000000000000000000000085
:108BF0000000000000000000000000000000000075
:108C00000000000000000000000000000000000064
:108C10000000000000000000000000000000000054
:108C20000000000000000000000000000000000044
:108C30000000000000000000000000000000000034
:108C40000000000000000000000000000000000024
:108C50000000000000000000000000000000000014
:108C60000000000000000000000000000000000004
:108C700000000000000000000000000000000000F4
:108C800000000000000000000000000000000000E4
:108C900000000000000000000000000000000000D4
:108CA00000000000000000000000000000000000C4
:108CB00000000000000000000000000000000000B4
:108CC00000000000000000000000000000000000A4
:108CD0000000000000000000000000000000000094
:108CE0000000000000000000000000000000000084
:108CF0000000000000000000000000000000000074
:108D00000000000000000000000000000000000063
:108D10000000000000000000000000000000000053
:108D20000000000000000000000000000000000043
:108D30000000000000000000000000000000000033
:108D40000000000000000000000000000000000023
:00000001FF

C:\SysGCC\avr\bin>

While you *could* do this in the menus of AS4 I think setting the project to "Use external Makefile" then using a manually edited makefile might be easier. Start by getting AS4 to create one as usual in the ./Debug or./Release directory then switch to external and modify that with the extra -Wl,-section-start's and a modified avr-objcopy for the .hex

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson

Glad to inform you i am right now working with your way & seems working !

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After build total array of data i am getting this error-

 

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe: Tab_2560.elf section .TABLE12 will not fit in region data

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe: region data overflowed by 45918 bytes

 

 

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What was the base address for that one? But the bottom line may be simply that there is not enough room in the chip. I assume that along with these data tables there's plenty of code to process them?

 

BTW do yourself a favour and ditch the 6 year old compiler. Get a shiny 4.9.2 from Atmel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you'll have to ensure no one array straddles a 64K boundary

Doesn't that depend on how you access them?  if you actually use them as arrays (pgm_read_byte_far(pgm_get_far_address(table1[i]))), straddling the boundary will be a problem, but if you're accessing some sort of consecutive data like:

   uint32_t p = pgm_get_far_address(table1);
    ... pgm_read_byte_far(p++);

it should work OK?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have installed AVR Studio 6.2 , hope that will work.

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson 

i have installed - Atmel Studio 6 (Version: 6.2.1563 - Service Pack 2

PLease guide me once more with this version.

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The advice hasn't changed - just that you are now using a C compiler and linker that have about 5 years more bug fixes and additional features. What happens if you now try to build the same code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear Clawson,

Just now i have build the project without any error. 

As AVR 6.2 is new to me it took little bit of time, any how little bit of googling and your previous article in this community i came to this point.

But i have a little doubt of keeping data in proper place. My final data table is like - 

Start Segment Total Byte In Decimal
.Table1=0x10000 2000
.Table2=0x107D0 9584
.Table3=0x12D40 608
.Table4=0x12FA0 14992
.Table5=0x16A30 336
.Table6=0x16B80 14992
.Table7=0x1A610 352
.Table8=0x1A770 2000
.Table9=0x1AF40 7008
.Table10=0x1CAA0 9984
.Table11=0x1F1A0 400
.Table12=0x1F330 3200
.Table13=0x1FFB0 7200
.Table14=0x21BD0 400
.Table15=0x21D60 12800
.Table16=0x24F60 800
.Table17=0x25280 3984
.Table18=0x26210 368
.Table19=0x26380 400
.Table20=0x26510 512
.Table21=0x26710 5600
.Table22=0x27CF0 176
.Table23=0x27DA0 3200
.Table24=0x28A20 9600

 

 

And i am getting the .LSS Table like this - 

GccApplication3.elf:     file format elf32-avr
 
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000056  00800200  000014c2  00001676  2**0
CONTENTS, ALLOC, LOAD, DATA
  1 .TABLE24      00002580  00800256  00001518  000016cc  2**0
CONTENTS, ALLOC, LOAD, DATA
  2 .TABLE23      00000c80  008027d6  00003a98  00003c4c  2**0
CONTENTS, ALLOC, LOAD, DATA
  3 .TABLE22      000000b0  00803456  00004718  000048cc  2**0
CONTENTS, ALLOC, LOAD, DATA
  4 .TABLE21      000015e0  00803506  000047c8  0000497c  2**0
CONTENTS, ALLOC, LOAD, DATA
  5 .TABLE20      00000200  00804ae6  00005da8  00005f5c  2**0
CONTENTS, ALLOC, LOAD, DATA
  6 .TABLE19      00000190  00804ce6  00005fa8  0000615c  2**0
CONTENTS, ALLOC, LOAD, DATA
  7 .TABLE18      00000170  00804e76  00006138  000062ec  2**0
CONTENTS, ALLOC, LOAD, DATA
  8 .TABLE17      00000f90  00804fe6  000062a8  0000645c  2**0
CONTENTS, ALLOC, LOAD, DATA
  9 .TABLE16      00000320  00805f76  00007238  000073ec  2**0
CONTENTS, ALLOC, LOAD, DATA
 10 .TABLE15      00003200  00806296  00007558  0000770c  2**0
CONTENTS, ALLOC, LOAD, DATA
 11 .TABLE14      00000190  00809496  0000a758  0000a90c  2**0
CONTENTS, ALLOC, LOAD, DATA
 12 .TABLE13      00001c20  00809626  0000a8e8  0000aa9c  2**0
CONTENTS, ALLOC, LOAD, DATA
 13 .TABLE12      00000c80  0080b246  0000c508  0000c6bc  2**0
CONTENTS, ALLOC, LOAD, DATA
 14 .TABLE11      00000190  0080bec6  0000d188  0000d33c  2**0
CONTENTS, ALLOC, LOAD, DATA
 15 .TABLE10      00002700  0080c056  0000d318  0000d4cc  2**0
CONTENTS, ALLOC, LOAD, DATA
 16 .TABLE01      000007d0  00020000  00020000  0000fbcc  2**0
CONTENTS, ALLOC, LOAD, DATA
 17 .TABLE02      00002570  00020fa0  00020fa0  0001039c  2**0
CONTENTS, ALLOC, LOAD, DATA
 18 .TABLE03      00000260  00025a80  00025a80  0001290c  2**0
CONTENTS, ALLOC, LOAD, DATA
 19 .TABLE04      00003a90  00025f40  00025f40  00012b6c  2**0
CONTENTS, ALLOC, LOAD, DATA
 20 .TABLE05      00000150  0002d460  0002d460  000165fc  2**0
CONTENTS, ALLOC, LOAD, DATA
 21 .TABLE06      00003a90  0002d700  0002d700  0001674c  2**0
CONTENTS, ALLOC, LOAD, DATA
 22 .TABLE07      00000160  00034c20  00034c20  0001a1dc  2**0
CONTENTS, ALLOC, LOAD, DATA
 23 .TABLE08      000007d0  00034ee0  00034ee0  0001a33c  2**0
CONTENTS, ALLOC, LOAD, DATA
 24 .TABLE09      00001b60  00035e80  00035e80  0001ab0c  2**0
CONTENTS, ALLOC, LOAD, DATA
 25 .text         000014c2  00000000  00000000  000001b4  2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
 26 .bss          00000044  00800256  00001518  0001c66c  2**0
ALLOC
 27 .comment      00000030  00000000  00000000  0001c66c  2**0
CONTENTS, READONLY

 

Pkdas

Last Edited: Thu. Nov 3, 2016 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pkd0057 wrote:
But i have a little doubt of keeping data in proper place
I'm not sure what you are asking?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if i am writing: 

-Wl,-section-start=.Table1=0x10000

 

__attribute__((section(".TABLE1"))) uint8_t TABLE1[5] =
{1,2,3,4,5};

 

Then in flash memory section, the first element/byte should start from address 0x10000.

then in output file the compiler/linker should write like - 

0x10000 = 1

0x10001 = 2

0x10002 = 3

0x10003 = 4

0x10004 = 5

 

Where to check the correctness of this arrangement ?

 

I have checked after build program as per post no#18 but not finding any relevance data in that particular location  specified in section information.

 

 

 

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The .map file

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now All is ok.

But i faced a new thing- 

if i am writing in -WI section :.TABLE01=0x08000

Only then TABLE01 data are placing from 0x10000 onwards----- why?

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where are you entering that setting? If its in the "Memories" section of Studio then note that because it takes the address as words not bytes so you must use values that are half the byte address you want.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right!

I used it in the memory section of AVR Studio 6.2

 

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then you should read the long explanatory note that Atmel have next to that dialog where they try to explain their crazy scheme for entering word addresses that then get doubled to byte addresses. The world works much smoother if everyone would just do all memory addressing in bytes! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmm,

again facing problem to read data & debug.

1>   i am using :             #define pgm_read_byte_far(address_long)     __ELPM((uint32_t)(address_long)). to read data but getting fail.

                                      char Data =   pgm_read_byte_far(0x10000) ;

2> As usual unable to add variable (data ) in watch list, i have read few post related to this but almost all procedure failed.

 

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

#8 (read it this time)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After migration of my platform from AVRStudio 4 to 6.2 i found it very difficult to write & fetch data as per the topic,  through as i am new with avrStudio 6.2, but finally i achieved my goal. This topic discussed earlier by different moderator but i asked only Mr. Clawson as i have seen most of thread are full of not to the point which consumes time . So it might be easier to follow for Mr. clawson about my problem & his valuable suggestions. Hope this topic may help others like me. Here are those procedure i have followed. I Don't know where this procedure is right or wrong , so other can give their suggestions  - 

 

1. Installed Atmel Software Framework from Atmel. It will asked automatically after open Atmel Studio 6.2, Internet connection is required.

2. I am using old dated PC AMD based with 1 GB ram, Os-Windows-7.Extremely Slow but works.

3. Read #8 in this thread. for overall procedure-- thanks Clawson for this.

4. Create a new project, New project Name should not have any "underscore" sign > _

5. Create a new header file from solution explorer.

6. copy & paste this code in that header file -- (as for example).

 

           __attribute__((section(".TABLE01"))) uint8_t TABLE01[0xNN] =
{

//your datas , NN = number of datas

7.Goto > Project Property >Toolchain >AVR/GNU Linker>Memory setting> Add Item , Paste this -> .TABLE01=0x8000

      As we want to keep data  in flash section starts from 0x10000 , divide by 2 shall be write of above path of our desired location.

8. set the folder path of newly created header file at Toolchain >AVR/GNU C Compiler> Directories.

9. set optimization level to -O1 at Toolchain >AVR/GNU C Compiler>optimization

10. Debugging level is default to -g2 at  Toolchain >AVR/GNU C Compiler>Debugging

11. Set Configuration at debug mode.

12. Lastly write #include <morepgmspace.h>

13.  write/add :-

       volatile long potol2;//declare as global var
       volatile char potol3;//declare as global var

14. In Main write:-

      potol2 = pgm_get_far_address(TABLE01[MM]); 
      potol3 = pgm_read_byte_far(potol2);

     NB: TABLE01[MM] , MM denotes the data position of table01, e.g. 0=1st data, 1=2nd data etc.

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Point 12 is wrong.  In this day and age you should not need morepgmspace.h because everything you need is in the standard pgmspace.h (that is pgm_get_far_address()). 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Clawson for your Addon note.

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having a little problem.

if i am writing in -WI section :.TABLE01=0x08000

then the data of TABLE01 shall come in the 0x10000 location & onwards of Flash area. But it is not showing whenever i am importing it in hex editor with intel hex format.

​Am i doing something wrong with the tool-chain setting ?

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pkd0057 wrote:
But it is not showing whenever i am importing it in hex editor with intel hex format.
Import into what?

 

The fact is that Intel Hex only supports 16 bit addressing so in theory can only access 64K. However at:

 

https://en.wikipedia.org/wiki/In...

 

you will read about record type 0x02 which is "extended segment address" so the hex that defines contents at 0x1???? should start with a 0x02 record giving the 0x1???? offset.

 

For example:

$ cat avr.c
#include <avr/io.h>

__attribute__((section(".himem"))) uint8_t data[] = { 1,2,3,4,5,6 };

int main(void)
{
    while(1);
}

$ avr-gcc -Os -mmcu=atmega2560 -Wl,-section-start=.himem=0x32148 avr.c -o avr.elf
$ avr-objcopy -O ihex -j .text -j .himem avr.elf avr.hex
$ cat avr.hex
:100000000C9472000C947E000C947E000C947E0084
:100010000C947E000C947E000C947E000C947E0068
:100020000C947E000C947E000C947E000C947E0058
:100030000C947E000C947E000C947E000C947E0048
:100040000C947E000C947E000C947E000C947E0038
:100050000C947E000C947E000C947E000C947E0028
:100060000C947E000C947E000C947E000C947E0018
:100070000C947E000C947E000C947E000C947E0008
:100080000C947E000C947E000C947E000C947E00F8
:100090000C947E000C947E000C947E000C947E00E8
:1000A0000C947E000C947E000C947E000C947E00D8
:1000B0000C947E000C947E000C947E000C947E00C8
:1000C0000C947E000C947E000C947E000C947E00B8
:1000D0000C947E000C947E000C947E000C947E00A8
:1000E0000C947E0011241FBECFEFD1E2DEBFCDBF46
:1000F00000E00CBF0E9480000C9481000C94000072
:06010000FFCFF894FFCFD1
:020000023000CC
:062148000102030405067C
:00000001FF

The key thing in all that is:

:020000023000CC

If you split it up to make it easier to read it is:

:02 0000 02 3000 CC

As the Wiki pages says:

The segment address from the most recent 02 record is multiplied by 16 and added to each subsequent data record address to form the physical starting address for the data. This allows addressing up to one megabyte of address space.

So the offsset here is 0x3000. That is multiplied by 16 to make it 0x30000 and that is then added to all subsequent data. So the next data record is:

:062148000102030405067C

which is really:

:06 2148 00 010203040506 7C

So there is my 1,2,3,4,5,6 data. It is at location 0x2148 but there is a 0x30000 offset in effect so this really 0x3000 + 0x2148 which is 0x31248 which matches:

-Wl,-section-start=.himem=0x32148

that I asked for.

 

So does your .hex contains 0x02 records?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Doesn't that depend on how you access them?  if you actually use them as arrays (pgm_read_byte_far(pgm_get_far_address(table1[i]))), straddling the boundary will be a problem, but if you're accessing some sort of consecutive data like:

 

hi, westfw

Suppose i am using 4 section of memory - 

 

//TABLE01 starts from 0x10000

__attribute__((section(".TABLE01"))) uint8_t TABLE01[4] =
{

    1,2, 3, 4

};

 

//TABLE02 starts from 0x10010

__attribute__((section(".TABLE02"))) uint8_t TABLE01[4] =
{

5,6,7,8

 

//TABLE03 starts from 0x10020

__attribute__((section(".TABLE03"))) uint8_t TABLE01[4] =
{

    9,10,11,12

};

 

 

//TABLE04 starts from 0x10030

__attribute__((section(".TABLE04"))) uint8_t TABLE01[5] =
{

    13,14,15,16,17

};

 

How to access data of any table out of 4 table as per my selection of table.Simply switching data table as per my requirement.

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All four are called TABLE01 ??

 

(cut and paste accident?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ha its cut paste fever!!!

any how i m writing once again..

 

//TABLE01 starts from 0x10000

__attribute__((section(".TABLE01"))) uint8_t TABLE01[4] =
{

    1,2, 3, 4

};

 

//TABLE02 starts from 0x1F000

__attribute__((section(".TABLE02"))) uint8_t TABLE02[4] =
{

5,6,7,8

 

//TABLE03 starts from 0x1F700

__attribute__((section(".TABLE03"))) uint8_t TABLE03[4] =
{

    9,10,11,12

};

 

 

//TABLE04 starts from 0x1FF00

__attribute__((section(".TABLE04"))) uint8_t TABLE04[5] =
{

    13,14,15,16,17

};

 

 

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then your question of how to access data in table 4 is surely that you just pass &TABLE04[n] to pgm_read_byte() isn't it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

can i use to fetch data with this way ? 

 

 Data =   pgm_read_byte_far(0x10000)  

 

OR

 

 Data = pgm_read_byte_far(0x20000)

 

OR this way

 

 Data = pgm_read_byte_far(i)

where i = 0x10000 to 0x1F000.

or  i = 0x20000 to 0x20100.

 

 

 

 

 

Pkdas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd guess something like

data = pgm_read_byte_far(pgm_get_far_address(TABLE04) + index);