[U-Boot] embedded standalone app for AVR32

Hello all,
I have been struggling for weeks trying to get a u-boot application with interrupts running on an AVR32 STK1000 board.
I have been able to get the application to run properly when loaded directly to 0x00000000 flash memory complete with serial interfaces and interrupts.
I have also been able to get a small application (without serial and interrupts) to be successfully run and exit (correctly returning control to u-boot).
I just can't get these two pieces to run together. I have been in contact with Atmel and they provided me a linker script (included in zip file) which got my app to run at a different location in memory.
I'm a bit of a newbie to embedded programming so I apologize if I ask any dumb questions.
To simplify my issues I created this extremely stripped down version of my app to isolate my issues.
Blink.c
#include <avr32/io.h>
#include <sys/interrupts.h>
volatile struct avr32_pio_t *piob=&AVR32_PIOB;
unsigned int PIN_MASK = 0x00000003;
volatile struct avr32_rtc_t *rtc=&AVR32_RTC;
volatile unsigned int number_of_blinks = 0;
__int_handler *rtc_cb();
int main (int argc, char *argv[])
{
piob->per = PIN_MASK;
piob->oer = PIN_MASK;
piob->idr = PIN_MASK;
piob->pudr = PIN_MASK;
piob->codr = PIN_MASK; /* set LED's to low */
number_of_blinks = 0;
unsigned int clock_msec_precision = 500;
struct avr32_rtc_ctrl_t rtc_control_register;
rtc_control_register.topen = 1;
rtc_control_register.pclr = 0;
rtc_control_register.en = 1;
rtc_control_register.psel = 0;
rtc->CTRL=rtc_control_register;
rtc->val = 0x00000000;//initial val=0
rtc->top = 16 * clock_msec_precision;
rtc->ier |= AVR32_RTC_IER_TOPI_MASK;//interrupt enabled
set_interrupts_base( (void *) AVR32_INTC_ADDRESS );
register_interrupt( (__int_handler) (rtc_cb), AVR32_RTC_RTC_IRQ/32, AVR32_RTC_RTC_IRQ%32, INT0);
init_interrupts();
while ( number_of_blinks < 40);
return (0);
}
__int_handler *rtc_cb()
{
// clear the interrupt
rtc->icr |= AVR32_RTC_ICR_TOPI_MASK;
number_of_blinks++;
// toggle the led
if ( piob->pdsr&PIN_MASK)
piob->codr=PIN_MASK;
else piob->sodr=PIN_MASK;
return (void *) 0;
}
Building this app with "avr32-gcc blink.c -o blink" and loading it to 0x00000000 runs fine.
I attached a small project which I received from atmel which provided assembly for a _start routine, a linker script and a make file.
With some modifications to the Makefile I was able to run code, similar to above that blinked an LED but did NOT USE interrupts. This code was able to be loaded and run from various points of flash and SDRAM.
When I included the interrupts in this application I was receiving __heap_start__ and __heap_end__ undefined (along with a few other minor linking errors that I fixed due to gcc libraries that were not linked in). I attempted to define these areas in the linkerscript and was able to get my app to build but it would not run. I attempted many different iterations defining the heap sections unsuccessfully. FWIW I also attempted to allocate some memory using malloc to see if the heap was the problem and that wouldn't run either.
Hopefully I made myself clear in this e-mail but my ultimate goal is to run an embedded app under u-boot, exit and boot to linux.
I would prefer if I could run the app in SDRAM but I really don't care where it runs as long as it works.
All help is greatly appreciated.
Sean Flynn Sean.Flynn@HexagonMetrology.com mailto:Sean.Flynn@HexagonMetrology.com
Senior Software Engineer
Hexagon Metrology, Inc
Brown & Sharpe division
250 Circuit Drive
North Kingstown, RI, 02852
phone: 1-401-886-2686
fax: 1-401-886-2228
www.HexagonMetrology.us http://www.HexagonMetrology.us

"FLYNN Sean" Sean.Flynn@hexagonmetrology.com wrote:
When I included the interrupts in this application I was receiving __heap_start__ and __heap_end__ undefined (along with a few other minor linking errors that I fixed due to gcc libraries that were not linked in). I attempted to define these areas in the linkerscript and was able to get my app to build but it would not run. I attempted many different iterations defining the heap sections unsuccessfully. FWIW I also attempted to allocate some memory using malloc to see if the heap was the problem and that wouldn't run either.
Please keep talking to support about this. It sounds like a problem with the linkerscript you're using and has nothing to do with u-boot.
Hopefully I made myself clear in this e-mail but my ultimate goal is to run an embedded app under u-boot, exit and boot to linux.
I don't think you can return to u-boot if you reprogram the interrupt controller, or alter any other hardware that u-boot is using.
Haavard

Dear Haavard Skinnemoen,
In message 20080912111701.1bd3cc33@hskinnemo-gx745.norway.atmel.com you wrote:
I don't think you can return to u-boot if you reprogram the interrupt controller, or alter any other hardware that u-boot is using.
You can, if you make sure to save the previous state before changing it, and restore it before returning to U-Boot.
Best regards,
Wolfgang Denk

Wolfgang Denk wrote:
Dear Haavard Skinnemoen,
In message 20080912111701.1bd3cc33@hskinnemo-gx745.norway.atmel.com you wrote:
I don't think you can return to u-boot if you reprogram the interrupt controller, or alter any other hardware that u-boot is using.
You can, if you make sure to save the previous state before changing it, and restore it before returning to U-Boot.
Best regards,
Wolfgang Denk
IOW, if you sow mines as you leave basecamp, mark them very carefully on the map so that you can pick them all up again when you return or one of them will go *BANG*. :-O
gvb

I suspected the linkerscript was the issue.
Can anyone point me in the right direction to a correct linker script for my purposes or even a good online source on how to correctly edit or generate a linker scripts with regards to interrupts/heap/stack/etc allocation rules/guidelines?. I have tried editing these on my own (using scripts from Atmel, gnu script for the atap7000 chips, u-boot and freertos) with no luck.
I'm having difficulty understanding why my app isn't working. I'm guessing I'm close but I'm missing a piece of this puzzle.
Best regards, Sean
Sean Flynn Sean.Flynn@HexagonMetrology.com Senior Software Engineer Hexagon Metrology, Inc Brown & Sharpe division 250 Circuit Drive North Kingstown, RI, 02852 phone: 1-401-886-2686 fax: 1-401-886-2228 www.HexagonMetrology.us
-----Original Message----- From: Haavard Skinnemoen [mailto:haavard.skinnemoen@atmel.com] Sent: Friday, September 12, 2008 5:17 AM To: FLYNN Sean Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] embedded standalone app for AVR32
"FLYNN Sean" Sean.Flynn@hexagonmetrology.com wrote:
When I included the interrupts in this application I was receiving __heap_start__ and __heap_end__ undefined (along with a few other
minor
linking errors that I fixed due to gcc libraries that were not linked in). I attempted to define these areas in the linkerscript and was
able
to get my app to build but it would not run. I attempted many
different
iterations defining the heap sections unsuccessfully. FWIW I also attempted to allocate some memory using malloc to see if the heap was the problem and that wouldn't run either.
Please keep talking to support about this. It sounds like a problem with the linkerscript you're using and has nothing to do with u-boot.
Hopefully I made myself clear in this e-mail but my ultimate goal is
to
run an embedded app under u-boot, exit and boot to linux.
I don't think you can return to u-boot if you reprogram the interrupt controller, or alter any other hardware that u-boot is using.
Haavard

"FLYNN Sean" Sean.Flynn@hexagonmetrology.com wrote:
I suspected the linkerscript was the issue.
Can anyone point me in the right direction to a correct linker script for my purposes or even a good online source on how to correctly edit or generate a linker scripts with regards to interrupts/heap/stack/etc allocation rules/guidelines?. I have tried editing these on my own (using scripts from Atmel, gnu script for the atap7000 chips, u-boot and freertos) with no luck.
I don't know. Linker scripts inevitably end up being highly dependent on the run-time framework you're using (e.g. newlib, the AVR32 Software Framework, ...) so it's hard to come up with any general guidelines. U-Boot and Linux both use custom linker scripts because they provide the whole run-time environment themselves, and they have a few special requirements (special sections for initcalls, commands, etc.)
If you're using newlib, you should use the default linker scripts that are included with the standalone toolchain. If they don't work, that's a bug which we should look into. I've never really been involved with newlib much, not even as a user, so I think your best bet is to talk to Atmel support if this is the case.
I'm having difficulty understanding why my app isn't working. I'm guessing I'm close but I'm missing a piece of this puzzle.
Yes...it's difficult to write linker scripts, especially when you don't know the run-time environment intimately.
Haavard
participants (4)
-
FLYNN Sean
-
Haavard Skinnemoen
-
Jerry Van Baren
-
Wolfgang Denk