[U-Boot] embedded standalone app for AVR32

[U-Boot] embedded standalone app for AVR32

[FLYNN Sean]

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 at 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> 

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hexagon.zip
Type: application/x-zip-compressed
Size: 4869 bytes
Desc: hexagon.zip
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080911/1a4dc7e0/attachment-0001.bin 

[U-Boot] embedded standalone app for AVR32

[Haavard Skinnemoen]

"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

[U-Boot] embedded standalone app for AVR32

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Testing can show the presense of bugs, but not their absence.
                                                   -- Edsger Dijkstra

[U-Boot] embedded standalone app for AVR32

[Jerry Van Baren]

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

[U-Boot] embedded standalone app for AVR32

[FLYNN Sean]

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 at 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 at atmel.com] 
Sent: Friday, September 12, 2008 5:17 AM
To: FLYNN Sean
Cc: u-boot at 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

[U-Boot] embedded standalone app for AVR32

[Haavard Skinnemoen]

"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