AVR-gcc >> where is specified the sram size for mmcu =

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

As i am currently working on the FPSLIC AT94K uC, I would like to know where is specified the sram data size for avr-gcc (ie how avr-gcc knows that: Data: 3871 bytes (94.5% Full) ?)
As the .data memory size on the FPSLIC can be extended, I would like to specify avr-gcc that my ram is not 4k but 12K...

My electronic projects blog >> www.limpkin.fr

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

It might be looking at RAMEND in the .h file.

Regards,
Steve A.

The Board helps those that help themselves.

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

That's what I thought too... however, when changing the RAMEND variable to the appropriate value... I still have the same error (and my program still won't work...

My electronic projects blog >> www.limpkin.fr

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

There are XML parts description files in Studio. Try finding the one for your part (AVR Tools/Partdescriptionfiles?) and decoding it (look for terms like SRAM). Don't know for sure if that's what you need, but it's a start.

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

well... I found a file C:\WinAVR-20090313\avr\lib\avr5\crtat94k.o (at94k is avr5 architecture) that seems to play an important role concerning the memory locations but i can't be sure of it as it is non human readable...

My electronic projects blog >> www.limpkin.fr

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

ps: i can't find xml description files for each mmcu...

My electronic projects blog >> www.limpkin.fr

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

So I try to reallocate the heap into the extended memory: no problem at all (-Wl,--defsym=__heap_start=0x802000,--defsym=__heap_end=0x802fff)
I thus conclude that putting data into the extended sram is not a problem but it seems that changing the RAMEND value to put the stack at the end of the extended sram doesn't make any difference...

My electronic projects blog >> www.limpkin.fr

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

sorry for all the messages....
when setting the stack end to the extended memory i can check through debugging that it has correctly been done... but when my data size is longer than the nominal memory, the program won't start... what could cause such problem?

My electronic projects blog >> www.limpkin.fr

Last Edited: Wed. Feb 24, 2010 - 11:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sorry for all the messages....
when setting the stack end to the extended memory i can check through debugging that it has correctly been done... but when my data size is longer than the nominal memory, the program won't start... what could cause such problem?

My electronic projects blog >> www.limpkin.fr

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

Quote:
ps: i can't find xml description files for each mmcu...
Their in the AVR Studio program directory.

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

I don't know anything about the '94k, but you I think you can change the stack location by defining to the linker the __stack symbol with the address wanted.

I don't think the compiler/linker really care anything about sizes, as long as there are no section 'collisions'.

'avr-size', which reports the section sizes, may be 'fixed' in what it thinks the '94k is set to.

This thread should probably be in the gcc forum instead of here.

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

Well, I tried adding the option -Wl,--defsym=__stack=0x802fff, without success...
I'm gonna see with avr-size what it tells me...

My electronic projects blog >> www.limpkin.fr

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

Avr size:

F:\PROJET_LED_MATRIX\avr_led_matrix\default>avr-size --mcu=at94k led_matrix.elf

text data bss dec hex filename
5788 3904 1703 11395 2c83 led_matrix.elf

and:

F:\PROJET_LED_MATRIX\avr_led_matrix\default>avr-size -C --mcu=at94k led_matrix.
elf
AVR Memory Usage
----------------
Device: at94k

Program: 9692 bytes (29.6% Full)
(.text + .data + .bootloader)

Data: 5607 bytes (136.9% Full)
(.data + .bss + .noinit)

My electronic projects blog >> www.limpkin.fr

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

If you are asking how avr-size -C knows the size of devices then note that the -C support is a patch to the base avr-size program and if you have WinAVR installed then that patch is in:

C:\WinAVR-20100110\source\avr\binutils\2.19\30-binutils-2.19-avr-size.patch

Within that file you will see:

+	{"at94k",         AVR32K,  AVR4K,  0UL},

in which the AVR4K is setting the size of the RAM to be 4096 bytes:

+#define AVR4K 4096UL

If you wanted to cange this you'd need to get the avr-size source, apply this patch then modifiy the "4K" (or modify the patch then apply), then build the utility.

If you are using Windows and need an avr-size.exe then you will have to look at setting up an MinGW/MSYS build environment in order to build it in the same way that Eric does for WinAVR

BTW as the only thing that's really wrong here is the % figure and you want to have 12K rather than 4K I'd just use the existing tool as is and just set your "barrier" at 300% rather than 100% - trying to build your own avr-size would be a HUGE undertaking (which is why there's only one person in the known universe who does so under Windows)

(BTW moving this thread to GCC...)

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

Thanks a lot for your answer clawson
.
This is thus for the avr-size program... so could you lighten me up about the main reason why my program doesn't work even if i specified the stack to be in the extended memory knowing that this memory is accessible?

My electronic projects blog >> www.limpkin.fr

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

Does the CPU have JTAG? If so, with no program at all I'd just probe memory at the expected locations and verify that it does exist at those addresses first.

BTW a 12K SRAM will not have RAMEND (and hence SP init) at 0x2FFF - it would be 0x2fff++<0x20_for_32_registers>

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

Actually the SP is at 0x2FF0 when entering the main...
The FPSLIC has JTAG but never used.
Are you suggesting that the linker option making the stack at the end of the extended ram doesn't work?

My electronic projects blog >> www.limpkin.fr

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

The linker option works. I'm suggesting that you may be placing it in the wrong location (before the end of actual SRAM).

Take a mega128 for instance - it's published SRAM is 4K so you might think it ran from 0x0000 to 0x0FFF but this is not the case the actual memory map is:

0x0000 32 AVR registers
0x0020 64 SFRs
0x0060 160 extended SFRs
0x0100 SRAM
0x10FF end of SRAM

So you wouldn't set _stack to 0x800000+4K-1 (0x800FFF) you set it to 0x800000+32+64+160+4K-1 (0x8010FF)

For 12K you were setting it to 0x800000+12K-1. I'm saying this should be 0x800000+32++12K-1

That was all.

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

Without changing anything, the RAMEND var was set to 0x0FFF, now i set it to 0x2FFF (plus the linker option) and i am still able to run programs... but whose data sizes are less than 0x0FFF... that is the strange part...

My electronic projects blog >> www.limpkin.fr

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

Show us the .map file of your >0x0FFF data project.

JW

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

Here it is http://pastebin.com/DYeGSxB2 (150%)

My electronic projects blog >> www.limpkin.fr

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

you'll notice a weird data length...

My electronic projects blog >> www.limpkin.fr

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

I have no idea why this does not work.

What happens if you take your working <100% project and inflate data artificially with a dummy big array?

JW

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

I'm gonna try... normally it should be working as the stack is already in the extended ram...

My electronic projects blog >> www.limpkin.fr

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

Quote:
you'll notice a weird data length...
if you are referring to the data 'Length' under Memory Configuration (0x0000ffa0), that is pretty much meaningless (notice how it lets you 'have' all space below the eeprom section, even though you can't use it all).

I would suspect some configuration problem in the avr. Looks like some bits need to be set correctly to partition the sram.

You could be setting the stack to a functional state (0x00802fff, which appears correctly for 12k), but still have the sram incorrectly configured. If this thing acts like a 'normal' avr, setting the stack to a higher value than possible simply 'wraps' the stack address, pointing to an address that 'works'. For example, if set to 0x2FFF, it may actually be pointing to physical sram addressed at 0x0FFF with the upper bits ignored in this case. You could then be running into problems when data is too large, just like 'normal'.

So maybe tell us how you know you have the sram partitioned correctly.

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

well, i'm gonna write from the program directly into the extended sram memory and i will let you know how it goes...

My electronic projects blog >> www.limpkin.fr

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

Keep in mind when you write to 'extended' ram with the sections incorrectly set, it will 'wrap' to a valid physical address (I'm assuming its like a normal avr). In your case, the 'wrap' would be a nice symmetrical wrap for 12bits (0x0000=0x1000=0x2000).

Maybe write to 0x0100 and 0x1100 to see if they are the 'same' physical byte.

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

don't worry, i'll be writing with the avr side of the fpslic and checking with the fpga side...

My electronic projects blog >> www.limpkin.fr

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
send_data_to_fpga(0x2c, FPGA_ADDR2_REGISTERH);
send_data_to_fpga(0xff, FPGA_ADDR2_REGISTERL);
(memory area to be scanned from the fpga side)
unsigned char* data_pter = (unsigned char*)0x2000;
unsigned int ii;
for(ii = 0; ii < 0x0FFF; ii++)
*data_pter++ = (unsigned char)ii;

works perfectly.... the data read by the fpga after the for loop is executed is different from the one before...

edit: however, when overwriting the data between 0x2000 and 0x2fff (where my stack is supposed to be), i don't have any crash.... so my stack is not where it is supposed to be?

My electronic projects blog >> www.limpkin.fr

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
data_pter = (unsigned char*)0x0F00;
	for(ii = 0; ii < 0x0100; ii++)
		*data_pter++ = (unsigned char)ii;

doesn't make my program crash either.
where is my stack?

My electronic projects blog >> www.limpkin.fr

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

1. confirm you have the ram partitioned correctly (SCR40-41? -like I know anything about this thing)

2. look at the lss listing, find where the stack register is set (.init2, although you may not see the section name listed, the map file will tell you where it is)

3. confirm you can write/read extended sram from the avr side- something like _MMIO_BYTE(0x0100)=0;_MMIO_BYTE(0x1100)=1;_MMIO_BYTE(0x2100)=2;, then read them back to see if 0x0100 remains 0, etc. If 0x0100 changed, then go to step 1.

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

1. confirmed
2. where can you find it in the lss file? i tried to look for the addr of the SP register, without success
3. will do it soon

My electronic projects blog >> www.limpkin.fr

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

1) but this was my point earlier. You may believe you've set the right control register/bits (or whatever it is?) to configure for 12K of RAM but the only way you are going to prove that it really is where you think it is and properly activated is by connecting up a JTAG (JTAGICEmkII, Dragon, etc.) and manually probing the boundary memory addresses. Write 0xAA to 0x2FFF or wherever you think the boundary is and see if it is retained - also check through at other page boundaries to ensure there hasn' been an address wrap and it appears at multiple locations (which are really a wrap of the same location)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
switch_off_led();
	unsigned char* data_pter = (unsigned char*)0x0100;
	_MMIO_BYTE(0x0100)=0;
	_MMIO_BYTE(0x1100)=1;
	_MMIO_BYTE(0x2100)=2;
	if(*data_pter != 0x00)
		switch_on_led();
	data_pter = (unsigned char*)0x1100;
	if(*data_pter != 0x01)
		switch_on_led();
	data_pter = (unsigned char*)0x2100;
	if(*data_pter != 0x02)
		switch_on_led();
	while(1);

worked... i can access the extended memory from the avr side...

My electronic projects blog >> www.limpkin.fr

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

Just to confirm that i'm really writting to the correct addresses in the extended ram:
using the fpga and its sdram control lines (read write / adress / data) i am able to directly contact the extended memory, without any logic present between my driver & the sram memory. Thus, i am able to verify that my data has been written at the correct address

My electronic projects blog >> www.limpkin.fr

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

Quote:
2. where can you find it in the lss file? i tried to look for the addr of the SP register, without success
It will more than likely be right after the vector table, and in the map file you posted earlier, .init2 starts at 0x00000090 (line 202). You should see clearing of r1, maybe clearing of sreg, and a couple out's to the sp.

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

stack is correctly set to 0x2FFF >

      94:	cf ef       	ldi	r28, 0xFF	; 255
      96:	df e2       	ldi	r29, 0x2F	; 47
      98:	de bf       	out	0x3e, r29	; 62
      9a:	cd bf       	out	0x3d, r28	; 61

My electronic projects blog >> www.limpkin.fr

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

Well, I guess you're going to have to chip away at the problem. It appears the gcc side of things presents no problems, and the only unusual thing that is required is to set the __stack to match the sram configuration.

Another thing you could try, is to move the .data section up to 0x00801000 (via linker section address option), along with setting the __stack to 0x0080FFF (stack using 'normal' ram, data uses 'extended'). I'm not sure what that would tell you, but it may provide a clue.

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

well i can try yes... will the heap will automatically be set at the end of the .data?

My electronic projects blog >> www.limpkin.fr

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

Well, I tried to put the data making the .data more than 100% in a separate memory section:

LOAD c:/winavr-20090313/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr5/crtat94k.o
                0x00802fff                __stack = 0x802fff
                0x00801000                .init3 = 0x801000

Still bricks my firmware....

moreover, if i put the big data i use in this memory section, i got this message:

F:\PROJET_LED_MATRIX\avr_led_matrix\default/../main.c:65: warning: internal error: out of range error

My electronic projects blog >> www.limpkin.fr

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

I'm not sure why you are using .init3 like that, which is a section located in the .text section (in the linker script). I suspect that would cause weird problems no matter what avr you used.

I was thinking more like so-

-Wl,--section-start,.data=0x801000,
--defsym=__stack=0x800fff

-which means its kind of a reversal of normal (like using external ram for the data, and internal for the stack). Again, I don't know what it will tell you, but it may tell you something.

If you don't use functions that use the heap (like malloc), don't worry about the heap.

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

Well, i tried something else:

avr-gcc -mmcu=at94k -Wl,--section-start,.data=0x801000,--defsym=__heap_end=0x802fff 

ie: put the stack at its original place 0x0fff and put the data & heap after.
And i still have the same problem of the 4K limitation! if the data section is more than 4k... my program won't boot.

My electronic projects blog >> www.limpkin.fr

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

Are you aware of the fact that your extra data SRAM is taken from the program SRAM (it is 12k smaller then)? Are you aware of the fact that a copy of the .data section is located in the program area (initialization values)?

So, is your program memory still big enough for the program and the copy of the .data section?

And are you sure the program SRAM is correctly loaded from the external media on startup?

Stefan Ernst

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

Yes, I'm aware of that. In any case, there is enough place in the program area.
And I'm also sure that the program SRAM is correctly loaded :(

My electronic projects blog >> www.limpkin.fr

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

Well apparently i don't have the 4k problem anymore...
But the problem still appears when the data section is more than 120%...
when the program size is between 8k4 and 10k4... which corresponds to nothing in particular (knowing that i have 12k x16 available for the program section)

My electronic projects blog >> www.limpkin.fr

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

no one for this strange new limitation? :(

My electronic projects blog >> www.limpkin.fr

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

If you have 12K of RAM and you are told at compile time that .data is 8K4 .. 10K4 then that represents 70% .. 87%. It's a rough rule of thumb but once your static .data/.bss reaches about 75% it's a fair bet that your dynamic (stack based) usage is going to consume the other 25%

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

actually it is 12k * 16, not 12k * 8, and when compiled my compiler tells me that the memory is 30% full :(

My electronic projects blog >> www.limpkin.fr