This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: dsr_list not initialized as NULL
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Yi Tang <yitang at itee dot uq dot edu dot au>
- Cc: eCos-discuss <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 08 Jan 2008 04:44:25 -0700
- Subject: Re: [ECOS] dsr_list not initialized as NULL
- References: <001b01c851e9$c19b7640$82406682@itee.uq.edu.au>
Yi Tang wrote:
Hi All,
I'm working with ecos on an soft-core processor on Xilinx FPGA ml401
board. And I found that the
Cyg_Interrupt::dsr_list[CYGNUM_KERNEL_CPU_MAX] (it is an single
processor system) in my system is not initialized as NULL. Thus it cause
the dsr_pending() check to always be true and also cause the system
point to invalid pointer.
Since the dsr_list is defined as volatile, just wondering if the HAL
level has some funtion to alter it and cause the trouble? Or it is
simply the memory on FPGA not initialized with all zero?
I found the same .exe file works fine on the simulation processor on my
host computer.
inline cyg_bool Cyg_Interrupt::DSRs_pending()
{
HAL_SMP_CPU_TYPE cpu = CYG_KERNEL_CPU_THIS();
#ifdef CYGIMP_KERNEL_INTERRUPTS_DSRS_TABLE
return dsr_table_head[cpu] != dsr_table_tail[cpu];
#endif
#ifdef CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST
return dsr_list[cpu] != NULL;
#endif
};
Everything which ends up in 'bss' (such as unitialized
arrays) should be zeroed when eCos starts up.
What architecture (CPU core) is in your FPGA? The code
that does this is in the eCos startup code, typically:
hal/<arch>/arch/current/src/vectors.S
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss