View topic - Basic UART puts() function won't work how I expect.

Search

Basic UART puts() function won't work how I expect.
Previous 1, 2 All

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR forum

Author

Message

bobgardner

Posted: Jun 09, 2012 - 01:43 PM

Joined: Sep 04, 2002
Posts: 21251
Location: Orlando Florida

Well, how about commenting out the continue in the while in the putchar? (Once again, one of those gee I'll try this to see if it works test)

_________________
Imagecraft compiler user

benjwy

Posted: Jun 09, 2012 - 02:00 PM

Joined: Jun 07, 2012
Posts: 13

Removing the continue didn't change things. I really appreciate you all giving your time to this problem I must say.

This seems significant:

I created a dummy function (I tend to call these things "weasel")

Declaring (inside main):

Code:

char *message = "Hello!";

This outputs 'H' (as expected)

Code:

void weasel(char *str)

{

    uart_putchar(str[0]);

}

This however, crashes things.

Code:

void weasel(char *str)

{

    uart_putchar(str[1]);

}

sternst

Posted: Jun 09, 2012 - 02:13 PM

Joined: Jul 23, 2001
Posts: 2437
Location: Osnabrueck, Germany

Please check the address where the global data is stored. Perhaps this is one of the cases where it accidentally starts at 0x60 instead of 0x100.

_________________
Stefan Ernst

david.prentice

Posted: Jun 09, 2012 - 02:21 PM

Joined: Feb 12, 2005
Posts: 16271
Location: Wormshill, England

Your avr-gcc build looks fairly recent. Winavr-2010 is gcc version 4.3.3

However, Winavr builds are tried and tested.
Atmel Toolchain works fairly well.
Bingo's Linux builds are tried and tested.

I strongly suspect that your toolchain is seriously broken. And it is mystery to me why anyone should choose an 'unusual' build.

I will quite happily run Rowley Crossworks on Ubuntu and have a reliable compiler / debugger / IDE.
I don't mind compiling with avr-gcc on Ubuntu something that is already debugged.

Otherwise, why not use the best tools for the job. This probably means running or emulating Windows.

David.

benjwy

Posted: Jun 09, 2012 - 02:26 PM

Joined: Jun 07, 2012
Posts: 13

sternst wrote:

Please check the address where the global data is stored. Perhaps this is one of the cases where it accidentally starts at 0x60 instead of 0x100.

Code:

00800060 <__data_start>:

  800060:       48 65           ori     r20, 0x58       ; 88

  800062:       6c 6c           ori     r22, 0xCC       ; 204

  800064:       6f 21           and     r22, r15

        ...

Is this the info you're after? That's my string in there Wink

sternst

Posted: Jun 09, 2012 - 02:37 PM

Joined: Jul 23, 2001
Posts: 2437
Location: Osnabrueck, Germany

benjwy wrote:

Is this the info you're after?

Yes, and this

Code:

00800060 <__data_start>:

should be 00800100 instead.

Try to find a toolchain without that bug, or as a workaround put this into the command line:

Code:

-Wl,-Tdata=0x100

_________________
Stefan Ernst

benjwy

Posted: Jun 09, 2012 - 02:45 PM

Joined: Jun 07, 2012
Posts: 13

sternst wrote:

benjwy wrote:

Is this the info you're after?

Yes, and this

Code:

00800060 <__data_start>:

should be 00800100 instead.

Try to find a toolchain without that bug, or as a workaround put this into the command line:

Code:

-Wl,-Tdata=0x100

You. Are. The. Man. I can't thank you enough.

Just so I can learn something from this all, could you please tell me what tipped you off to this, and how you knew that the .data section should start at 0x0100, but might be at 0x0060 by mistake?

Thank-you very much to everyone who helped!

david.prentice

Posted: Jun 09, 2012 - 03:35 PM

Joined: Feb 12, 2005
Posts: 16271
Location: Wormshill, England

avr-gcc is often built by people who don't follow all the news / patches / bug reports.

Personally, I wait until a new build has 'settled down' before using it. i.e. let the others have the grief.

AFIK, the 0x0060 / 0x0100 feature is a build problem.
Most of the Atmel Toolchain features are down to Atmel putting typos in their typos into XML files. Then creating duff system header files.

David.

clawson

Posted: Jun 09, 2012 - 07:45 PM

Joined: Jul 18, 2005
Posts: 62230
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

could you please tell me what tipped you off to this,

When you use code such as this:

Code:

    char message[7];

    message[0] = 'H';

    message[1] = 'e';

    message[2] = 'l';

    message[3] = 'l';

    message[4] = 'o';

    message[5] = '!';

    message[6] = 0;

the compiler generates code along the lines of:

Code:

  LDI YL, low(message)

  LDI YH, high(message)

  LDI R24, 'H'

  ST  Y+, R24

  LDI R24, 'e'

  ST  Y+, R24

  LDI R24, 'l'

  ST  Y+, R24

etc.

that is the actual data initialisers ('H', 'e', 'l'..) are built into the code image. When you use:

Code:

char message[] = "Hello!";

No code is immediately generated for this. Instead the string "Hello!" is tagged onto the end of the code image (after .text) and the C compiler simply relies on the fact that the C Run Time (CRT) code that runs before the entry to main() will have a _do_copy_data loop that knows the sizxe of all the initial values in the .data copy following .text in flash and it (in theory!) knows where .data will ultimately be located in RAM then it just does an LPM based copying loop to block copy the entire data from the flash copy and out to RAM. In your case to the wrong place.

Stefan would have recognised that:

Code:

char message[] = "Hello!";

is relying on _do_copy_data and you would not believe the number of thread we get here were someone's home brew makefile has an avr-obcopy command that does something like:

Code:

avr-obcopy -O ihex -j .text proj.elf proj.hex

when ,if -j's are to be used, it should be:

Code:

avr-obcopy -O ihex -j .text -j .data proj.elf proj.hex

as you also want a copy of .data in the .hex file. Both Stefan and I thought that's why your objcopy must be wrong and like him I was slightly surprised when you presented an avr-objcopy command that apparently does not suffer from the "missing .data syndrome" that we see so regularly.

But the reason why the .data stuff was missing in your case is far more pernicious. If your Linux can install .deb then go to my website and get one there:

www.wrightflyer.co.uk/avr-gcc/

By the way your avr-objcopy is NOT safe if you ever use <avr/eeprom.h> or <avr/fuse.h> or <avr/lock.h> so I'd suggest you also seek out "Mfile" and use it to generate your Makefile's (or at least just steal the "good stuff" from its makefile_template),

_________________

snigelen

Posted: Jun 09, 2012 - 08:09 PM

Joined: Jan 08, 2009
Posts: 1148
Location: Lund, Sweden

Since he's using a FreeBSD port of avr-gcc, I guess he's using FreeBSD. Isn't Jörg the maintainer of that port?

benjwy

Posted: Jun 10, 2012 - 01:21 AM

Joined: Jun 07, 2012
Posts: 13

Thanks for the in-depth reply clawson, it's appreciated. Now that I look in my datasheet, I see that RAM starts at 0x100. At least I learned something from you guys Smile

@snigelen, correct. I think he maintains all of the AVR-related ports. I was unsure whether to send a PR to him, or someone else.

Cheers.

engineer.pk

Posted: Jun 16, 2012 - 08:43 PM

Joined: Aug 12, 2011
Posts: 44
Location: Pakistan

The error may be in
void my_puts(char *str)
{
while (*str) {
uart_putchar(*str++);
}
}

change it to
{
while (*(str) != '\0') {
uart_putchar(*str++);
}
}

Last edited by engineer.pk on Jun 16, 2012 - 08:49 PM; edited 1 time in total

Jump to:

All times are GMT + 1 Hour

Previous 1, 2 All

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » AVR forum

AVRFreaks.net

Search