AVR Freaks

Level: Hangaround

Joined: Wed. May 3, 2006

Posts: 259 View posts

Location: India

Posted by yellowboy_75: Tue. Nov 10, 2009 - 07:30 AM

First time seen this error,

The first below not able to understand

The second one looks flash size overflow. But may not true as I am using mega128 and maximum flash size is 128 * 1024 = 131072 bytes, the error starts from 196673!!!

c:\.....\LOCALS~1\Temp/ccCabaaa.s:799314: Error: value of 199818 too large for field of 2 bytes at 16

c:\.....\LOCALS~1\Temp/ccCabaaa.s:396469: Error: value of 65536 too large for field of 2 bytes at 196673

Reading your experiences about this will be a great learning experience!!

Tools, Compilers and General Programming, ATmega128

Tags:

Last Edited: Wed. Nov 11, 2009 - 04:47 PM

david.prentice

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 28938 View posts

Location: Wormshill, England

Posted by david.prentice: Tue. Nov 10, 2009 - 08:49 AM

an int16_t variable can only hold 16 bits: -32768 .. +32767
a uint16_t: 0 .. 65535

I can only guess that the assembly file that produced the error was being asked to store a constant .DC.W that is out of the 16 bit range.

It is nothing to do with memory size. Your C file may need to use a 'long' variable type so that the generated S file uses .DC.L for the constant.

David.

Level: Hangaround

Joined: Wed. May 3, 2006

Posts: 259 View posts

Location: India

Posted by yellowboy_75: Tue. Nov 10, 2009 - 09:01 AM

Quote:

I can only guess that the assembly file that produced the error was being asked to store a constant .DC.W that is out of the 16 bit range.

It is nothing to do with memory size. Your C file may need to use a 'long' variable type so that the generated S file uses .DC.L for the constant.

I have hundreds [edited here]97660 line of same code [/edit ends here] of lines of code, all same lines from start to end (inside main())

PORTA=0xff;

There is nothing apart from this line in the code.
No variable declaration, no function call..

[edit]I want to see how a 128KB flash hex file looks like[/edit]

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

Posted by wek: Tue. Nov 10, 2009 - 09:21 AM

Even if a PORTA=0xff would be compiled in a single instruction, 97660 x 2 bytes/instruction = 195320bytes > 128kB

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 96037 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Tue. Nov 10, 2009 - 09:21 AM

Why not generate the .s files (either "make file.s" or use -save-temps) and see what the offending line relates to and which source line generated it.

I'm astonished that "ccCabaaa.s:799314" is an asm file with over three quarter of a million lines in it! Have you never heard of "modularisation" ?!?

cmhicks

Level: Hangaround

Joined: Thu. Nov 20, 2008

Posts: 340 View posts

Location: Cambridge, UK

Posted by cmhicks: Tue. Nov 10, 2009 - 09:29 AM

You seem to be saying that your source file is like this:

int main(void) {
    PORTA = 0xff;
    PORTA = 0xff;
    // ...this repeated >97600 times...
    PORTA = 0xff;
    PORTA = 0xff;
}

in which case...

Either: You may be running out of FLASH. Assuming "PORTA = 0xff;" compiles to a single instruction (ie 2 bytes on AVR) there will be >128kBytes of code. But in this cse it would be puzzling to see an error from the assembler.

Or: The compiler is trying to be clever and has a bug. Can the optimiser -Os setting spot a repeated instruction like this and attempt to turn it into a loop? If so it may erroneously assume that the assembler can cope with a loop counter >65535. This would explain the assembler complaining, rather than the linker.[EDIT: Not so sure about this now]

Christopher Hicks
==
[EDIT:

Quote:

I'm astonished that "ccCabaaa.s:799314" is an asm file with over three quarter of a million lines in it!

Crikey, I hadn't spotted that. I think maybe there's a small bug in the compiler/assembler when dealing with very large source files, maybe encoding line numbers within the debug symbol table or something.]

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

Posted by wek: Tue. Nov 10, 2009 - 09:49 AM

I've just tried to compile 100k lines of PORTA = 0xFF, for ATM2561 it compiles OK, for 128k it compiles and assembles but won't link (no surprise).

I don't see the above said symptoms.

Level: Hangaround

Joined: Wed. May 3, 2006

Posts: 259 View posts

Location: India

Posted by yellowboy_75: Tue. Nov 10, 2009 - 09:57 AM

Quote:

I've just tried to compile 100k lines of PORTA = 0xFF, for ATM2561 it compiles OK, for 128k it compiles and assembles but won't link (no surprise).

I don't see the above said symptoms.

JW

I tried initially with ATmega256 but WinAVR (avrgcc) said unknown device type

What have you used to compile for m256?

I am using avr-gcc (GCC) 3.4.5

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

Posted by wek: Tue. Nov 10, 2009 - 10:00 AM

yellowboy_75 wrote:

I am using avr-gcc (GCC) 3.4.5

That's quite an old one. You might want to download some of the newer. Do you use WinAVR?

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 96037 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#10

Posted by clawson: Tue. Nov 10, 2009 - 10:12 AM

Just out of interest what IS the application here? If it's really 10's of thousands of "PORTA = NN" then why do it that way? Why not:

uint8_t data[] = { NN, MM, OO, PP...};
uint16_t data_ptr=0, i;

for (i=0; i

Or are you saying the "overhead" is too much? But this unrolling seems astronomically inefficient in terms of writing source.

Cliff

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#11

Posted by wek: Tue. Nov 10, 2009 - 10:14 AM

Cliff, meet yellowboy:

clawson wrote:

Just out of interest what IS the application here?

yellowboy wrote:

I want to see how a 128KB flash hex file looks like

david.prentice

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 28938 View posts

Location: Wormshill, England

#12

Posted by david.prentice: Tue. Nov 10, 2009 - 10:29 AM

The simplest way to see what a 128k hex file looks like is to just READ the flash contents to a hex file.

Neither an empty flash or a populated flash give very exciting bedtime reading. But perhaps it interests yellowboy.

David.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 96037 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#13

Posted by clawson: Tue. Nov 10, 2009 - 10:49 AM

How about:

#include 

	.macro gencode from=0, to=100
	ldi r16, \from
	out _SFR_IO_ADDR(PORTA), r16
	.if \to-\from
	gencode "(\from+1)",\to
	.endif
	.endm

	.global main
main:
	gencode 0,99
	gencode 100,199
	gencode 200,255
	gencode 0,99
	gencode 100,199
	gencode 200,255
	gencode 0,99
	gencode 100,199
	gencode 200,255
// and continue in this fashion...
loop:
	rjmp loop

(sadly this relies on a recursive macro and there's a nesting limit but it seems OK split into 100 at a time). The generated code looks like:

	.global main
main:
	gencode 0,99
  6c:	00 e0       	ldi	r16, 0x00	; 0
  6e:	0b bb       	out	0x1b, r16	; 27
  70:	01 e0       	ldi	r16, 0x01	; 1
  72:	0b bb       	out	0x1b, r16	; 27
  74:	02 e0       	ldi	r16, 0x02	; 2
  76:	0b bb       	out	0x1b, r16	; 27
  78:	03 e0       	ldi	r16, 0x03	; 3
  7a:	0b bb       	out	0x1b, r16	; 27
  7c:	04 e0       	ldi	r16, 0x04	; 4
  7e:	0b bb       	out	0x1b, r16	; 27
  80:	05 e0       	ldi	r16, 0x05	; 5
  82:	0b bb       	out	0x1b, r16	; 27
  84:	06 e0       	ldi	r16, 0x06	; 6
  86:	0b bb       	out	0x1b, r16	; 27
  88:	07 e0       	ldi	r16, 0x07	; 7
...

Cliff

PS there's no "cleverness" in this by the way - I just plagiarised the example from the manual:

file:///C:/WinAVR-20090313/doc/binutils/as.html/Macro.html#Macro

Level: Hangaround

Joined: Wed. May 3, 2006

Posts: 259 View posts

Location: India

#14

Posted by yellowboy_75: Tue. Nov 10, 2009 - 11:01 AM

wek wrote:

Cliff, meet yellowboy:

clawson wrote:
Just out of interest what IS the application here?

yellowboy wrote:
I want to see how a 128KB flash hex file looks like

A simple single interest I have:

"A 256KByte hex file for mega256, will be #linked type file # or same as a 1KB flash file for mega8 for hello world app"

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 96037 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#15

Posted by clawson: Tue. Nov 10, 2009 - 12:08 PM

Not quite it will have an 02 (Extended Segment Address Record) each time the code splits over a 64K byte boundary. For example:

Quote:

:100000000C942A000C943F000C943F000C943F0089
:100010000C943F000C943F000C943F000C943F0064
:100020000C943F000C943F000C943F000C943F0054
:100030000C943F000C943F000C943F000C943F0044
:100040000C943F000C943F000C943F000C943F0034
:100050000C943F0011241FBECFE5D4E0DEBFCDBF1E
:1000600010E0A0E6B0E0EAE8F0E002C005900D92F2
:10007000A636B107D9F70E9441000C9443000C94B6
:0A00800000000000FECFF894FFCF4F
:06008A004523EFBEADDED0
:020000023000CC
:0600000082E188BB0895B7
:00000001FF

This resulted from:

avr-gcc -mmcu=atmega16 -Wl,-Map=test.map -Wl,-section-start=.fred=0x30000 test.o empty.o    -lm  -o test.elf

You can see the 0x30000 embedded in that 02 record which offsets the following into the third fourth quadrant of a 256K device.

Cliff

Level: Hangaround

Joined: Wed. May 3, 2006

Posts: 259 View posts

Location: India

#16

Posted by yellowboy_75: Wed. Nov 11, 2009 - 04:04 PM

Quote:

:0A00800000000000FECFF894FFCF4F
:06008A004523EFBEADDED0
:020000023000CC
:0600000082E188BB0895B7
:00000001FF

Good input..
This shows that address 0x008A with Data 45h is from first quadrant
and
address 0x0000 with data 82h is the "first" byte from Fourth quadrant i.e. 0x3000

Is this what you mean to say?

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 96037 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#17

Posted by clawson: Wed. Nov 11, 2009 - 04:28 PM

Yes, there's no mystery about Intel Hex it is widely documented. The address field in a "normal" type 00 record is just 4 hex nybbles (2 bytes, one 16bit word) wide so can only address bytes 0..65536

In order to get beyond this the type 02 record is introduced which allows a further 16 bit value to be prepended (after a 4 bit left shift) as an offset to any subsequent records. This effectively extends from 16 bit to 20 bit addressing allowing for 1MiB of code. As the largest AVR is just 256KiB it easily fits into this.

If AVRs ever got beyond 20bit addressing then the Intel 04 record allows following records to be offset by 16 bis, allowing for 32bit addressing and access to 4GiB of memory space.

See: http://en.wikipedia.org/wiki/Int...

Cliff

Level: Hangaround

Joined: Wed. May 3, 2006

Posts: 259 View posts

Location: India

#18

Posted by yellowboy_75: Wed. Nov 11, 2009 - 04:47 PM

Thanks Cliff for to the point solution

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 96037 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#19

Posted by clawson: Wed. Nov 11, 2009 - 04:58 PM

Oh my dear God - so this whole thread was about your inability to use Google? If you wanted to know more about the Intel Hex format would the obvious thing not have been to simply type "Intel Hex" into Google? If you did that then, not surprisingly, the very top hit is that link I just gave you.

Ho hum.

Level: Hangaround

Joined: Wed. May 3, 2006

Posts: 259 View posts

Location: India

#20

Posted by yellowboy_75: Wed. Nov 11, 2009 - 06:22 PM

Ohh no, this was not about the googlability..

I have plenty of documents for iHex

But had no real hex file for m256

If you look at hex file generated by Keil for 8051 & by some other assemblers for 8051 then you ill find a great difference between the length of each line.

Most of the assemblers and compilers generates hex with fix length of each line in hex and thus wanted to see the mega256 full hex file for more details.

Thus I made the repeat lines as stated in the first post but got in to errors, thought this error may be new / unseen / rare so shared it here and the topic turned from resolving the error to the hex file internals which was my internal interest but was not the motive to post it here...

Google is my best friend... but I have learn over years not to trust the ready made data, as there may be minor hidden details important to the related work.