[ECOS] How to know if the scheduler is already running

Bart Veer bartv@ecoscentric.com
Tue Jun 23 14:49:00 GMT 2009


>>>>> "Stano" == Stanislav Meduna <stano@meduna.org> writes:

    Stano> Hi,
    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( &current->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> initialized.

    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

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



More information about the Ecos-discuss mailing list