[ECOS] Dual Init of SPI on at91sam7x-based system
Christophe Coutand
ccoutand@stmi.com
Tue Dec 7 23:07:00 GMT 2010
It seems to be a bug in there. From spi_at91_init.cxx, the following
definition is not visible : CYGBLD_ATTRIB_C_INIT_PRI
Possibly because of the compiler switch (__cplusplus) ?
----------- cyg_type.h -------------
#if defined(__GNUC__) && !defined(__cplusplus) && (__GNUC_VERSION__ >=
40300)
// Equivalents of the above for C functions, available from gcc 4.3
onwards.
# define CYGBLD_ATTRIB_C_INIT_PRI( _pri_)
__attribute__((constructor (_pri_)))
# define CYGBLD_ATTRIB_C_INIT_BEFORE( _pri_ )
__attribute__((constructor (_pri_-100)))
# define CYGBLD_ATTRIB_C_INIT_AFTER( _pri_ )
__attribute__((constructor (_pri_+100)))
#endif
An easy work around is to keep the C++ constructor only:
#1 In spi_at91_init.cxx -> remove #ifndef CYGBLD_ATTRIB_C_INIT_PRI /
#endif
#2 In spi_at91.c -> replace
#ifndef CYGBLD_ATTRIB_C_INIT_PRI
# define CYGBLD_ATTRIB_C_INIT_PRI(x)
#endif
void CYGBLD_ATTRIB_C_INIT_PRI(CYG_INIT_BUS_SPI)
cyg_spi_at91_bus_init(void)
{
with:
void
cyg_spi_at91_bus_init(void)
{
Then you should get the SPI bus initialized only once.
Christophe
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Bob Brusa
Sent: 7. desember 2010 15:31
To: Sergei Gavrikov
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Dual Init of SPI on at91sam7x-based system
Am 03.12.2010, 11:56 Uhr, schrieb Sergei Gavrikov
<sergei.gavrikov@gmail.com>:
> On Fri, 3 Dec 2010, Bob Brusa wrote:
>> I have a small program to run tests with lwip. It worked. Then I
>> updated from my ecos to the current version, built the library and
>> built my program. When launching it, it produces the message:
>>
>> ASSERT FAIL: <1>intr.cxx[506]void Cyg_Interrupt::attach() Interrupt
>> vector not
>> free.
>>
>> When digging into this message, I find that the SPI-bus0 is
>> initialized twice. The loop in hal_misc.c
>>
>>
>> for (p = &CONSTRUCTORS_START; p != CONSTRUCTORS_END;
>> NEXT_CONSTRUCTOR(p))
>> (*p)();
>>
>> calls the spi-bus0-initialization twice (copied from the debugger):
>>
>> 2 cyg_spi_at91_bus_init() spi_at91.c:196 0x00104eb0
>> 1 cyg_hal_invoke_constructors() hal_misc.c:213 0x00103f04
>>
>> The first time p is 0x2068e0, the second time 0x2068e4.
>>
>> And of course, this then produces the above assert fail-message. But
>> why is this constructor-table set up this way? And how can I fix
that?
>>
> My "discovery":
>
> Look at arguments and points of view around this thread
> http://sourceware.org/ml/ecos-patches/2009-02/msg00068.html
>
> Perhaps, you will get a clue.
>
> Also, may be it is bad idea I never try it, try to manage that with
CDL
> option CYGSEM_HAL_STOP_CONSTRUCTORS_ON_FLAG (read a description on the
> option). Honestly speaking, I'm not sure that I correctly understood
it.
>
>
> Sergei
Hi Sergei
The link you give leads in the right direction, but the fix they did
there
is a) included in my ecos and b) my compiler is version 4.3.2 and hence
should be able to handle the issue. I have digged somewhat further into
the problem, but with so many macros that are defined or not defined,
used
or not used, I come to no conclusion and can not fix the problem. Is
someone out there who could help? A short summary of what I found since
my
last mail on this issue:
The address called with p = 0x2068e0 is 0x104eac and calls
cyg_spi_at91_bus_init in spi_at91.c
The address called with p = 0x2068e4 is 0x10252c and calls _cyg_io_init
in
ioinit.cxx and this latter than somehow also invokes the
cyg_spi_at91_bus_init. But as I said: I am still from understanding the
details and need help.
Thanks and regards Robert
--
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
More information about the Ecos-discuss
mailing list