Where's the avr32-gcc startup code?

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

I'm using avr32-gcc from the Cygwin command line, and I wonder if there's any startup code the compiler runs before running my code, or does my code begin executing from the get go?

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

Unless you link with -nostartfiles or -nostdlib, avr32-gcc will automatically link in a number of files from ${prefix}/avr32/lib and ${prefix}/lib/gcc/avr32/${version}. The final binary usually starts executing from the _start symbol, which is usually defined in crt0.o or crt1.o.

When it is done with all the library initialization stuff, it will call your main() function. It will usually do some cleaning up after the main() function returns as well.

If you call avr32-ld directly to do the linking instead of going through the avr32-gcc frontend, none of this will happen automatically, so you'll either have to define your own _start routine or link in the startfiles explicitly. The -v option to gcc is handy if you want to see what happens behind the scenes...

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

Actually I'm mainly concerned if any hardware initialization occurs in the startup. It's beginning to look like my digging into the startup will probably be too advanced for me since this is my first avr32 code.

In the environment of the AVR32 examples is there any hardware initialization before the example code begins executing? Or is the AVR32 state the same as defined for default power on after reset?

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

GregoryC wrote:
In the environment of the AVR32 examples is there any hardware initialization before the example code begins executing? Or is the AVR32 state the same as defined for default power on after reset?

I'm not really too familiar with the standalone toolchain or the examples. But the startup code normally has to do at least _some_ hardware initialization -- at the very least it has to zero out the .bss (zero-initialized) section and initialize the stack pointer. I don't know if it touches any peripherals.

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

Thanks for the help. My concern is the peripherals. I'm sure the startup does its .bss etc. fine and probably like most startups. My problem is that I'm having trouble comprehending the hardware environment including the default state.

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

Nothing is setup by default. So if you for instance want to use the SDRAM or MMC, you'll have to set it up first.

The easiest way to get started with stand-alone development is probably to pick up a couple of the basic appnotes at www.atmel.com/avr32. Setup the usart and a couple of the other peripherals as well

11011110101011011100000011011110

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

The thing is, those appnotes are wrong. They don't even compile without errors, as I have stated elsewhere in this forum.

However, you are right. I discovered how to set up my SDRAM (after fixing the buggy example/appnote and tossing the unnecessary code).

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

Good to hear you've got it up and running.

What sort of errors? I think a mail to avr32@atmel.com with the problems you've encountered would help alot.

11011110101011011100000011011110

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

I posted elsewhere in this forum what the problem is, that the header files were changed (ap7000.h and it's sub-headers) and some of the device abbreviations were changed, but the examples use the old code. I did email avr32@atmel.com about one of the examples, told them it was wrong and why it was wrong, so I feel no need to repeat the email about each of the examples or maybe all of them (I didn't try 100% of them).

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

You can find some working examples of C startup code for standalone applications (also without newlib) in the AP7000 port of FreeRTOS code database (there are some no FreeRTOS-specific code, like a simple LCD test program)

See for example :
http://ap7x-freertos.svn.sourcef...
http://ap7x-freertos.svn.sourcef...

and of course, you need matching linker files
for ex
http://ap7x-freertos.svn.sourcef...

Currently, there is almost no documentation but I can provide you some help

I have startup code that allow you to boot either from flash or u-boot (STK1000 and NGW) , with or without initializing the SDRAM (STk1000 only, NGW should come soon)

If you are using the latest GNU tool chain (not the one provided in the first release of the BSP), then the code can be found in the unstable_gnutoolchain0407 branch but I didn't have time to commit the latest fixes (there are on my computer at home)
I can commit them this evening (european time)

Ronan

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

Thanks for the info. I surfed the URLs you provided but was unable to find anything related to the LCD. The only reason I wanted to know the startup was to see if there was anything hardware specific other than initialize ram & CPU, which I guess there isn't any hardware initialization.

I'm running the GNU tool chain downloaded from the Atmel website, not the one on the CD. I can't find any code anywhere other than the application notes (example programs).

It would be very helpful if you could point me towards the LCD initialization code. I'm sure there's some somewhere but I haven't been able to find it.

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

Hey man, that second one is da bomb! :) I've been looking for that code, or code like that, for a couple of weeks. I was about ready to fly to Norway and drag the code out of Atmel while they kick and scream! ;)

Seriously, it's a great benefit for me to have a peek at how somebody else initialized a different LCD using the AP7000 LCDC, and your code appears to be that. I'm coding for a 5.7" 640x480 LCD from Data Image, and my deadline is less than three weeks away.

Thank you very much!!! :)

p.s. I'm curious if you work for Atmel.

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

>Thank you very much!!! Smile
You're welcome

Most of the code is copied from Linux kernel - I just remove support for other LCDs than the one used on the STK1000 and add a software spi for backlight setup (I was not able to make the hardware SPI work correctly at first place - Now I think I know why - I should try again)
All the clocks are setup the same way as the default linux kernel that was in the BSP v1.0.
BTW, the latest u-boot for AVR32 is able to handle the STK1000 - You should also look into the code . It is probably cleaner that my code.

Ronan

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

Thanks. Actually the code I was discussing above was perfect. I compared it to mine and aside from the structures referencing the LCD types (in my code I just #define things like HBP, HFP, VFP, VBP, etc.) there was no significant difference, even right down to my code and the reference code even initialized the registers in the same order. The only difference was waiting for the DMA engine to become idle before enabling it, and waiting for the LCDC to become idle before enabling it, which I added to my code but nothing changed.

I'm pretty close to getting it running, but there's one more bug to find.