This is the mail archive of the
mailing list for the eCos project.
Re: How to know if the scheduler is already running
- From: Bart Veer <bartv at ecoscentric dot com>
- To: Stanislav Meduna <stano at meduna dot org>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Tue, 23 Jun 2009 15:49:32 +0100
- Subject: Re: [ECOS] How to know if the scheduler is already running
- References: <4A40AD28.email@example.com>
>>>>> "Stano" == Stanislav Meduna <firstname.lastname@example.org> writes:
Stano> I am trying to get an application with a flash file system
Stano> running and I am stumbling upon the initialization order.
Stano> My SPI device is using an interrupt mode and this works in
Stano> a simple application that does the initialization in or
Stano> after cyg_user_start. However, after adding the
Stano> dependencies needed for a JFFS2 the cyg_io_init adds itself
Stano> to the constructors
Stano> #8 0x20820458 in cyg_flash_init (pf=<value optimized out>)
Stano> at /ecos-d/CygwinData/ecos/packages/io/flash/current/src/flash.c:241
Stano> #9 0x20811b30 in flashiodev_init (tab=<value optimized out>)
Stano> at /ecos-d/CygwinData/ecos/packages/io/flash/current/src/flashiodev.c:129
Stano> #10 0x20815bb8 in cyg_io_init ()
Stano> at /ecos-d/CygwinData/ecos/packages/io/common/current/src/iosys.c:105
Stano> #11 0x20814ab8 in cyg_hal_invoke_constructors ()
Stano> at /ecos-d/CygwinData/ecos/packages/hal/arm/arch/current/src/hal_misc.c:213
Stano> This results in the code using interrupts and DSR to be
Stano> called, the calling code does cyg_drv_cond_wait, the
Stano> scheduler tries to switch the context and right after
Stano> HAL_THREAD_SWITCH_CONTEXT( ¤t->stack_ptr, &next->stack_ptr );
Stano> the application crashes
Stano> Program received signal SIGTRAP, Trace/breakpoint trap.
Stano> 0x208372dc in cygmem_pool_heap1 ()
Stano> To me this looks like I am calling something that should be
Stano> called only from a thread context, before the kernel is
Stano> How can I know in a constructor code, whether it is safe to
Stano> call the mutexes/conditions/...? I have no problem to
Stano> revert to the polled mode in the startup code, if I know
Stano> when it is safe to switch to the interrupt-driven one.
This should not be an issue. If you look at e.g. the dataflash driver,
cyg_dataflash_init() calls df_detect_device() which calls
df_read_status() which performs a cyg_spi_transaction_transfer() with
the polled flag set to true. So the SPI driver should perform this
operation in polled mode, not interrupt-driven mode, and the driver
should spin rather than suspend.
So either the SPI driver is ignoring the polled flag, which is a bug
in the driver, or higher-level code is failing to set the polled flag
when it should. I have no way of telling which from the info supplied.
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss