AVR-GCC unstable at big project?

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

I'm working on a project that writen on CodevisionAVR, now I need to include uIP in it. But I only have uIP worked on AVR-GCC. So I tried to convert all code to AVR-GCC in Atmel-Studio 6.2.
At first it cost me 3 days to fix few hundred errors and more than a thousand warnings because of incompatibility. The result is more than 20K lines and ~120KB flash (ATmega128).
But it compiled very unstable, sometime it run 1/2 main and reset, sometime run a code that should not be run, sometime not work at all. just change the code a little and the result change completely. I try to change EXTRAM settings but not hope :(. any suggestions please?
The project use 64K EXTRAM, rtl8019, 2 UART, 1 timer, 1 PWM, 1 serial flash.

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

Software that size is bound to have bugs - it's your job as the programmer to fix them. While everyone blames the compiler when things don't work it's actually very very rare for problems you experience to be as a result of a fault in the compiler. it's more likely your misunderstanding of how it works (such as where in memory it locates things and so on).

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

Quote:
sometime run a code that should not be run

Often a telltale sign that you've thrashed return address data, i.e. overwritten (parts of) the stack. Easily happens e.g. if you overrun local/automatic string variables.

Codevision uses two stacks, one for local/automatic data and one for return addresses so an overrun of a local variable is much less likely to thrash return addresses.

You likely have had a bug (or several) all along, but perhaps didn't get quite the disastrous effects using CodeVision.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
Often a telltale sign that you've thrashed return address data, i.e. overwritten (parts of) the stack.

That can be right, I'll check more at that. But in my case sometimes it does not run right: in main(),I have somethings like printf("\rBegin debug") at begin, but after reset it run to some strange codes (led's blink) but the text's never printed.
Is the program certainly go to main() first despite the stack?
RAM setting: -Wl,-Tdata=0x802100,--defsym=__heap_end=0x80ee00
Data: 34491 bytes (842.1% Full)
Last 256 byte of EXTRAM is for rtl8019 interface.
hardware is MMNET01 minimodule so the hardware is OK.
I mostly use global strings, some rare cases use local/automatic strings with lenght ~<20Byte, and progress still not touch these cases yet.
I wrote all from crash and it worked for months so all I think of now is complier fault :roll:
(it's mid night now so I'll follow later)

Last Edited: Thu. Jul 31, 2014 - 05:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I have somethings like printf("\rBegin debug") at begin

But you must have stuff that does the fdev_setup_stream() and assigns stdout before that?

The fact is that as you use external RAM, if there were any kind of RAM fault then it could be that the very first RET after the very first CALL fails so nothing beyond that would work right.

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

And, since this is an ATmega128 - are you sure you have disabled the M103C fuse and that you are actually building for an ATmega128?

Quote:
I wrote all from crash and it worked for months so all I think of now is complier fault

"From scratch", I assume?

One thing to do is to cut down the project to a minimum and build it up again in stages, and see where the fault appears again.

And at the same time, insert checks for faults e.g. by using asserts that when they fail halt the program after somehow showing what specific assert that failed and perhaps some extra indicator of the details of the fault. Pity you've already used up both UARTs, or one of them could have been used for diagnostic messages.

The odds are may thousands to one that the bug is in your code rather than the compiler being at fault.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:

Codevision uses two stacks, one for local/automatic data and one for return addresses so an overrun of a local variable is much less likely to thrash return addresses.

(from another thread)
Quote:
Codevision handles flash and eeprom transparently.

In between these two comments, it sounds to me like you could easily have a program that worked fine when compiled with codevision, and failed to work at all when compiled with gcc, even WITHOUT actual "bugs" in either the code or the compilers.

For instance, if codevision automatically puts literal strings in flash rather than RAM (and for sure gcc doesn't) the use of such strings in your program could cause memory to be exhausted when compiled with gcc (full of strings), even though CV was OK.

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

Easiest way I've found to get software to work that way is to stuff 17 characters into char SomeString[16].

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

valentine89 wrote:
in main(),I have somethings like printf("\rBegin debug") at begin, but after reset it run to some strange codes (led's blink) but the text's never printed.
Is the program certainly go to main() first despite the stack?
Yes, but if your code references a null pointer, it will start running at the RESET vector without actually performing a device reset. This is sometimes referred to as a 'software' reset, but it is in no way an actual reset. Any peripherals your code configured including any interrupt sources you enabled will not have been returned to their power-on default states. That alone can wreak havoc.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

it's still print some texts yesterday, but now after some minor change it print none.
I tried change main() name, insert a new one:

static int uart_putchar(char c, FILE *stream);
static FILE mystdout = FDEV_SETUP_STREAM(uart_putchar, NULL,_FDEV_SETUP_WRITE);
static int uart_putchar(char c, FILE *stream)
{
	loop_until_bit_is_set(UCSR0A, UDRE);
	UDR0 = c;
	return 0;
}
int main(void)
{
	//PORT
	PORTE=0x03;
	DDRE=0x02;
	//EXTRAM 64K
	MCUCR=0x80;
	XMCRA=0x00;
	// USART0 Baud Rate: 115200 (Double Speed Mode)
	UCSR0A=0x02;
	UCSR0B=0x08;
	UCSR0C=0x06;
	UBRR0H=0x00;
	UBRR0L=0x10;
	stdout = &mystdout;
	while(1)
	{	
		printf("Hello, world!\n");
		_delay_ms(2000);
	};
}

Output now:
Program: 107466 bytes (82.0% Full)
Data: 34042 bytes (831.1% Full)
EEPROM: 2302 bytes (56.2% Full)
Print out nothing :shock: . Hardware still work fine with another fw. Am I miss somethings? :(

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

still if you use 831% of the ram there are something wrong!
My first guess is that you have a lot of text that needs to be moved to flash!

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

valentine89 wrote:
Am I miss somethings? :(
Uh, yeah:
Data:      34042 bytes (831.1% Full)

As already mentioned, AVR GCC doesn't automatically place string literals into flash. Code like this:

printf("Hello, world!\n"); 

Will consume SRAM. That one alone will take 16 bytes.

I'd be willing to bet you've got a lot more string literals, and other data like tables.

You need to learn about the __flash modifier, and the functions in <avr/pgmspace.h>

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

sparrow2 wrote:
still if you use 831% of the ram there are something wrong!
My first guess is that you have a lot of text that needs to be moved to flash!

That cost is real using of my project (Codevision output is similar), they are for global string buffers, and in temp main() right now they are not used but still cost.
Many subroutines is unused yet but still cost ROM, but main problems is why it did not work even with such a simple main()? is the complier confused by subroutines that still not be called?

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

Joey!

I guess he gets that figure because he is using external RAM. 64K of it. The memory consumption computations don't know about this, but only of the RAM internal to the '128, so the resulting numbers look really bad although they might not be.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Now is the time to show a complete build output, valentine89!

Also, let's make sure the M103C fuse isn't programmed.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Now is the time to show a complete build output, valentine89!

Also, let's make sure the M103C fuse isn't programmed.

Another idea is to toggle a digital I/O pin right after

 	UDR0 = c;

and look at the pin with an oscilloscope, a logic analyzer or have a LED connected to it (for the latter, make sure you send an odd number of chars, so that you can actually see any blinking).

And, most importantly: For the minimal test program above, post the code you actually have. The one above does not even compile. Yes, I added the includes needed and tried to build, but even with that it does not compile - you try it yourself and see where it fails...

It is totally meaningless to post code other than the one you have. It will send us on a wild goose hunt. It will waste everybody's time. Your computer/OS has ctrl-C/ctrl-V for a reason.

If that exact code builds for you, then the wrong AVR model is selected for the project.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I have not used external RAM with GCC but there must be a way to tell it about the extra RAM , how would it else know where to place the stack!

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

Quote:

I have not used external RAM with GCC but there must be a way to tell it about the extra RAM

Of-course there is.

But that's not the point. The point is that the avr-size utility does not know about the extra RAM. The avr-size utility is separate from the compiler/linker.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:

Also, let's make sure the M103C fuse isn't programmed.

Another idea is to toggle a digital I/O pin right after

 	UDR0 = c;

and look at the pin with an oscilloscope, a logic analyzer or have a LED connected to it (for the latter, make sure you send an odd number of chars, so that you can actually see any blinking).
...
It is totally meaningless to post code other than the one you have. It will send us on a wild goose hunt. It will waste everybody's time. Your computer/OS has ctrl-C/ctrl-V for a reason.


Thank JohanEkdahl for your suggestion.
M103C fuse isn't programmed, other fuse is normal.
I have a oscilloscope/logic analyzer so I tried: the PIN is on/off in main() by not in uart_putchar. The Main.c file is a mess so I did quote all but mainly parts. I think only with that the program will work despite of the rest.

# define F_CPU 16000000UL
#include 
#include 
#include 
static int uart_putchar(char c, FILE *stream);
static FILE mystdout = FDEV_SETUP_STREAM(uart_putchar, NULL,_FDEV_SETUP_WRITE);
static int uart_putchar(char c, FILE *stream)
{
	loop_until_bit_is_set(UCSR0A, UDRE);
	UDR0 = c;
	return 0;
}
int main(void)
{
	//PORT
	PORTE=0x03;
	DDRE=0x02;
	//EXTRAM 64K
	MCUCR=0x80;
	XMCRA=0x00;
	// USART0 Baud Rate: 115200 (Double Speed Mode)
	UCSR0A=0x02;
	UCSR0B=0x08;
	UCSR0C=0x06;
	UBRR0H=0x00;
	UBRR0L=0x10;
	stdout = &mystdout;
	while(1)
	{
		printf("Hello, world!\n");
		_delay_ms(2000);
	};
}

Code above did work with the hardware. But didn't work with the same hardware while in my project.

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

Quote:

Code above did work with the hardware

You missed my main point. That code does not even compile if you build in a project with the ATmega128 as the target. The compiler will protest over the UDRE - a register bit that does not exist on an ATmega128.

Post complete build output (do a clean and the a build, then switch over to the Output tab, copy everything and post it here).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Oop, I use Atmel studio 6.2. Build with Toolchain Flavour: Native. It build fine without error.

------ Rebuild All started: Project: GccApplication1, Configuration: Debug AVR ------
Build started.
Project "GccApplication1.cproj" (Clean target(s)):
Target "Clean" in file "D:\Programs\Atmel Studio 6.2\Vs\Compiler.targets" from project "D:\Google drive\Atmel studio\test\GccApplication1\GccApplication1.cproj" (entry point):
	Task "RunCompilerTask"
		Shell Utils Path D:\Programs\Atmel Studio 6.2\shellUtils
		D:\Programs\Atmel Studio 6.2\shellUtils\make.exe clean 
		rm -rf  GccApplication1.o   
		rm -rf  GccApplication1.d   
		rm -rf "GccApplication1.elf" "GccApplication1.a" "GccApplication1.hex" "GccApplication1.lss" "GccApplication1.eep" "GccApplication1.map" "GccApplication1.srec" "GccApplication1.usersignatures"
	Done executing task "RunCompilerTask".
Done building target "Clean" in project "GccApplication1.cproj".
Done building project "GccApplication1.cproj".

Build succeeded.
------ Rebuild All started: Project: GccApplication1, Configuration: Debug AVR ------
Build started.
Project "GccApplication1.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "D:\Programs\Atmel Studio 6.2\Vs\Compiler.targets" from project "D:\Google drive\Atmel studio\test\GccApplication1\GccApplication1.cproj" (target "Build" depends on it):
	Task "RunCompilerTask"
		Shell Utils Path D:\Programs\Atmel Studio 6.2\shellUtils
		D:\Programs\Atmel Studio 6.2\shellUtils\make.exe all 
		Building file: .././GccApplication1.c
		Invoking: AVR/GNU C Compiler : 4.8.1
		"D:\Programs\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -mrelax -g2 -Wall -mmcu=atmega128 -c -std=gnu99 -MD -MP -MF "GccApplication1.d" -MT"GccApplication1.d" -MT"GccApplication1.o"   -o "GccApplication1.o" ".././GccApplication1.c" 
		Finished building: .././GccApplication1.c
		Building target: GccApplication1.elf
		Invoking: AVR/GNU Linker : 4.8.1
		"D:\Programs\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-gcc.exe" -o GccApplication1.elf  GccApplication1.o   -Wl,-Map="GccApplication1.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mrelax -mmcu=atmega128  
		Finished building target: GccApplication1.elf
		"D:\Programs\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "GccApplication1.elf" "GccApplication1.hex"
		"D:\Programs\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "GccApplication1.elf" "GccApplication1.eep" || exit 0
		"D:\Programs\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "GccApplication1.elf" > "GccApplication1.lss"
		"D:\Programs\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "GccApplication1.elf" "GccApplication1.srec"
		"D:\Programs\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\bin\avr-size.exe" "GccApplication1.elf"
		   text	   data	    bss	    dec	    hex	filename
		    380	     28	      6	    414	    19e	GccApplication1.elf
	Done executing task "RunCompilerTask".
	Task "RunOutputFileVerifyTask"
				Program Memory Usage 	:	408 bytes   0,3 % Full
				Data Memory Usage 		:	34 bytes   0,8 % Full
	Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "GccApplication1.cproj".
Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').
Target "Build" in file "D:\Programs\Atmel Studio 6.2\Vs\Avr.common.targets" from project "D:\Google drive\Atmel studio\test\GccApplication1\GccApplication1.cproj" (entry point):
Done building target "Build" in project "GccApplication1.cproj".
Done building project "GccApplication1.cproj".

Build succeeded.
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========


but with Toolchain Flavor:WinAVR it's fail:

"D:\Programs\WinAVR\avr\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -mrelax -g2 -Wall -mmcu=atmega128 -c -std=gnu99 -MD -MP -MF "GccApplication1.d" -MT"GccApplication1.d" -MT"GccApplication1.o"   -o "GccApplication1.o" ".././GccApplication1.c" 
		'"D:\Programs\WinAVR\avr\bin\avr-gcc.exe"' is not recognized as an internal or external command,
		operable program or batch file.
		make: *** [GccApplication1.o] Error 1

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

Nevermind WinAVR. It's quite old now, and unless you know for sure you need that rather than a current too chain just ignore WinAVR.

It is "fascinating" that you manage to build without errors although you have "UDRE" in your source. As I said earlier, this bit name does not exist for ATmega128.

Is the most recent source above a verbatim copy of ALL the source text and pasted here with no editing at all?

I am still at Atmel Studio 6.1, and will not upgrade right now. Can someone else test this with the Atmel Toolchain that comes with 6.2?

Here's my build output from 6.1:

------ Build started: Project: valentine89, Configuration: Debug AVR ------
Build started.
Project "valentine89.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files\Atmel\Atmel Studio 6.1\Vs\Compiler.targets" from project "C:\Users\johan\Documents\Atmel Studio\6.1\valentine89\valentine89\valentine89.cproj" (target "Build" depends on it):
	Task "RunCompilerTask"
		C:\Program Files\Atmel\Atmel Studio 6.1\shellUtils\make.exe all 
		Building file: .././valentine89.c
		Invoking: AVR/GNU C Compiler : 3.4.2
		"C:\Program Files\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.2.1002\avr8-gnu-toolchain\bin\avr-gcc.exe"  -funsigned-char -funsigned-bitfields -DDEBUG  -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -mrelax -g2 -Wall -mmcu=atmega128a -c -std=gnu99 -MD -MP -MF "valentine89.d" -MT"valentine89.d" -MT"valentine89.o"   -o "valentine89.o" ".././valentine89.c"
		.././valentine89.c: In function 'uart_putchar':
C:\Users\johan\Documents\Atmel Studio\6.1\valentine89\valentine89\valentine89.c(9,2): 'UDRE' undeclared (first use in this function)
C:\Users\johan\Documents\Atmel Studio\6.1\valentine89\valentine89\valentine89.c(9,2): each undeclared identifier is reported only once for each function it appears in
		make: *** [valentine89.o] Error 1
	Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreBuild" in project "valentine89.cproj" -- FAILED.
Done building project "valentine89.cproj" -- FAILED.

Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Quote:

Can someone else test this with the Atmel Toolchain that comes with 6.2?

I can't do it in Windows/As6 but I have Atmel's 4.8.1 toolchain in Linux and get this:

$ avr-gcc -mmcu=atmega128 -Os -g avr.c -o avr.elf
$ 

So no error, no warning.

The reason there's no error with UDRE is because:

$ grep UDRE iom128.h
#define USART0_UDRE_vect_num	19
#define USART0_UDRE_vect		_VECTOR(19)
#define USART1_UDRE_vect_num	31
#define USART1_UDRE_vect		_VECTOR(31)
#define    UDRE         5
#define    UDRE1        5
#define    UDRE0        5

So it's there along with UDRE0 and UDRE1 (not sure why really?)

EDIT: well I suppose the reason is this (note "generic"):

/* USART Status Register A (generic) */
#define    RXC          7
#define    TXC          6
#define    UDRE         5
#define    FE           4
#define    DOR          3
#define    UPE          2
#define    U2X          1
#define    MPCM         0

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

Checking SVN "blame" that generic definition has been there a LONG time. The mystery here is how your 6.1 is throwing an error!

I guess Atmel took their private branch. At some point thought "what's this doing here" and removed it from their copy. Broke some code that relied on it and after feedback decided to put it back as it was.

What does your iom128.h look like around line 706:

http://svn.savannah.nongnu.org/v...

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

OK, that explains it.

So, now we are back to

Quote:
I have a oscilloscope/logic analyzer so I tried: the PIN is on/off in main() by not in uart_putchar.

Can we see the complete code, including the toggling parts?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I have some progress now :D , I know about WinAVR and worked on AVR more than 5 years, and the "Toolchain Flavour" is "WinAVR" since last 2 hours. But now I changed it to "Native", make some fix (_delay_ms fix and const char PROGMEM fix). Now it printed text, still stuck at some point but had progress. I'll work more at it tomorrow and report here ^^.
summary: seem WinAVR had some big bugs, cause my project can't print a word.

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

Using external ram with avr-gcc require a certain amount of genuflecting in a .init section.
I do not remember details.
This might help: http://www.atmel.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_ext_ram.html

Iluvatar is the better part of Valar.

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

It seems worked!
Thank you everyone!
Still need more fix on EEPROM usage but the complier seem stable now, I should found this "Toolchain Flavour" sooner :(

         "simple main()"          "simple main() put
                                   in a huge mess pj"
_____________________________________________________
WinAVR      untested                    not work
 GCC      (maybe work)             can't print text
_____________________________________________________
AV6.2
native        work                        work
 GCC

WinAVR is too old, avoid it for your future project.
I having a sick pain converting code from CVAVR to GCC. Thousands of warning, hundreds of error, more than 500 places need to fix EEPROM usage and the complier didn't give a warning or error so I must find and fix it one by one myself, need fix all the printf_P things too @@. I still doing it just because efforts spent to come to this point. I "did" think AtmelStudio is more potential than CVAVR, but maybe I was wrong.
EDIT:Can't create table in this forum, spaces between texts auto disapear/fixed...

Last Edited: Fri. Aug 1, 2014 - 07:11 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

valentine89 wrote:
Can't create table in this forum, spaces between texts auto disapear...
Use code tags.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

NOOOOOOOOOOOOOOOOOOOOOO!
It's unstable AGAIN!
It did run well most of functions then I try to fix some flash string arrays (I know how to), it run fine with one, but when I fix another one then the error "in push_reload, at reload.c:1360" appear. I search for it and found out that's a error that Atmel still not fix yet. @&*^&*$#$
I tried everything but the error appear each time that ^&(*(#$ flash string included.
I tried that string in a new project and it work.
I tried to write it a new way, it took near a minute to compile, but but run only some seconds, not touch the @&$^#& string yet then it reset again and again.
I have enough off GCC, I'll try to make UIP work on CVAVR and forget about last wasted 5 days.

const char A_strings[][4] PROGMEM={
	"A",
	"CP",
	"UM",
	"DU",
	"CU",
	"CSS",
	"IO",
	"CL",
	"NRF",
	"WA",
	"DA",
	"VA",
	"SM",
	"SS",
	"RST",
	"CT",
	"SP",
};
printf_P(PSTR("*S OK"),A_strings[4]);
(cant post the percent character so use *)

It's not about how to print a flash string, but about how the GCC compile out a uncertain result.

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

Quote:

how the GCC compile out a uncertain result.

Bullshit - the compiler is completely deterministic.

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

Hi!

valentine89, you use external memory and enable it in main(). But initialization of memory had been done before main().

Enable external memory in .init0 or .init1 section.

Ilya

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

When will 'valentine89' realise that it is thousands of times more likely that a problem is due to his ignorance than a bug in the compiler? (most all of us have come to that insight already..)

:roll:

----------

Dear 'valentine89': I'll reinterpret the coment of 501-g above for you:

Before your main() is executed the startup code has been accessing RAM already. E.g. setting up the heap and setting up the stack, copying values of initialized variables from flash to RAM etc.

Now, if you initialize RAM in main() this means that all those things have been done in the wrong place, i.e. in internal RAM instead of external.

For these kinds of citcumstances there has to be a way for the programmer to "sneak" some code ito the startup sequence, and quite early.

Other tool chains, like CV might solve this in another way by auto-generating code based on some project setting for external RAM, but AVBR-GCC does not do this. You will have to write the external RAM init code, and you wil have to place it at the right spot in the init sequence.

There are a number of "hooks" in the init sequence where you can "insert" code. This is the .init0, .init1 ... sections that 501-g talks about.

It is time for you to

1. do a proper read of the docuentation, and
2. stop nagging about GCC being unstable in this respect - the fault is at your end.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

valentine89 wrote:

(cant post the percent character so use *)

The forum software doesn't like % very much. Use % instead.

@JohanEkdahl has put together a Greasemonkey script to automate it for Firefox.

Personally, I compose my posts in a text editor and use search/replace before copy/paste back into my post.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Sorry for the nagging, I have a limit time but the converting takes a lot of patience. I don't have much time to learn all about GCC, and I'm doing a professional project but dun have anyone can help beside myself here :lol: .
I had a rest day and and think about it, CVAVR vs GCC: do what more familiar. I already knew 3-4 errors cause by CVAVR complier (so I tried to change), but it's OK because I knew how to prevent them (by experience :wink: ). I'll use CVAVR for time being then.
BTW, I've tried .init3 to init EXTRAM, still nothing new.

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

Quote:
BTW, I've tried .init3 to init EXTRAM, still nothing new.

Then again you are not listening. Using .init0 or .init1 was suggested, and there's a reason. .init3 does stack initialization and clearing of the zero register. Did you also do that when you initialized external ram? If not, the program is going to be in a completely untenable state when it starts up.

It has been said before. GCC works. Take the time to figure out why things aren't working and you'll be able to fix the problems ( in your code ). For a start, you can check the documentation of memory sections ( here http://www.nongnu.org/avr-libc/user-manual/mem_sections.html ). The .initN sections are described about halfway through.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

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

Quote:

Take the time to figure out why things aren't working

Ah but he said:
Quote:

, I have a limit time but the converting takes a lot of patience. I don't have much time to learn all about GCC,

but rather curiously then went on to say:
Quote:

and I'm doing a professional project

I'm not sure in what sense a professional wouldn't stop to work out how to do it properly rather than trying to rush and botch something together; but I guess it takes all sorts to make a world ;-)