RE: [ECOS] arm-eabi -> Interrupt vector not free

["Christophe Coutand" <ccoutand at stmi dot com>]

Hi Frank,

I think what you are describing is similar to this bug report:

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001096

Christophe

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Frank Pagliughi
> Sent: 23. juni 2011 23:58
> To: Reg
> Cc: eCos Discuss
> Subject: Re: [ECOS] arm-eabi -> Interrupt vector not free
> 
> On 04/12/2009 11:29 AM, Reg wrote:
> > Hello
> >
> > This error raises before ecos calls cyg_user_start. So it's in the
> > ecos startup. Earlier I spent days to get my gdb working (OpenOCD,
> > cygwin, windows, Atmel AT91 SAM7A3). With the tools shipped with ecos
> > it did not work, but with yagarto's toolchain it did, but I'm not
> able
> > to compile ecos with it, because configtool uses cygwin style path,
> > and yagarto uses windows style pathes.
> > An eabi has this error :) I will give a try with arm-eabi-gdb. If it
> > did not work, I would be in a hard situation :)
> >
> > Thank you!
> > Gergely Szentirmai
> >
> > Sergei Gavrikov írta:
> >> On Fri, Apr 10, 2009 at 11:03:10PM +0200, Szentirmai Gergely wrote:
> >>> Hello
> >>>
> >>> Previously I used arm-elf-gcc, but any time I try to get arm-eabi
> >>> alive  I get this this message imidiately after reset:
> >>>
> >>> <1>intr.cxx[506]void Cyg_Interrupt::attach() Interrupt vector not
> free.
> >>> ASSERT FAIL: <1>intr.cxx            [ 506] void
> Cyg_Interrupt::attach()
> >>>  Interrupt vector not free.
> >>
> >> First, what is your target (platform) and which interrrupt number
> is?
> >>
> >>> There is no message like this when I compile things with elf (two
> >>> changes, command prefix= arm-elf-gcc, and Build for eabi = false
> (it
> >>> is  done automatically)). The ecos config, and sources are the
> same.
> >>> There  is only one main.c, which would send hello world to the diag
> >>> port.  (works perfectly with elf). Nothing to do with interrupts.
> >>
> >> Can you set a breakpoint on cyg_assert_fail() and
> cyg_interrupt_attach()
> >> to know a bit more about issue? What is that vector? UART, RTC? The
> >> assertion's report will tell you about.
> >>
> >>> This message was discussed here:
> >>> http://ecos.sourceware.org/ml/ecos-discuss/2004-08/msg00099.html
> >>>
> >>> But my ecos source (latest from CVS) behaves like this.
> >>>
> >>> Any ideas? Maybe this magic build for eabi switch does something
> wrong?
> >>>
> >>
> >> It's not enough an information to get it.
> >>
> >> Sergei
> >>
> >>> Gergely Szentirmai
> >>>
> >>> --
> >>> Before posting, please read the FAQ:
> >>> http://ecos.sourceware.org/fom/ecos
> >>> and search the list archive: http://ecos.sourceware.org/ml/ecos-
> discuss
> >>
> >
> 
> I'm seeing this problem as well. Was there a resolution?
> 
> In my case I'm using the Atmel EB55 eval board (AT91M55800A chip). It
> seems that, when using the EABI compiler, the constructor for the SPI
> device gets called twice. Once through:
>    _GLOBAL_I.3200_spi_at91_init.cxx
> which eventually calls the cyg_spi_at91_bus_init() function.
> 
> But then it seems the cyg_spi_at91_bus_init() function is called
> directly, as if it's in the table of default constructors.
> 
> I'm using a default build and testing the example app, "twothreads".
> 
> Frank
> 
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss