RE: [ECOS] Threading on EDB7211

[Gary Thomas <gthomas@redhat.com>]

It looks to me like interrupts are not working properly for you.

Are you using the provided GDB stubs?
How did you configure your eCos kernel?

You could try and get a little more information.  In the file
  .../ecc/hal/arm/edb72xx/<VERSION>/src/edb72xx_misc.c
add some debug info as follows:

=========== code snippet ==============================================
int hal_IRQ_handler(void)
{
    struct regmap *map = hal_interrupt_status_regmap;
    cyg_uint32 stat;
    int vector;
    while (map->first_int) {
        stat = *(volatile cyg_uint32 *)map->stat_reg & *(volatile cyg_uint32 *)map->mask_reg;
// Add the following line
        diag_printf("IRQ - stat: %x\n", stat);
// Added line
        for (vector = map->first_int;  vector <= map->last_int;  vector++) {
            if (stat & hal_interrupt_bitmap[vector]) return vector;
        }
        map++;  // Next interrupt status register
    }
    hal_spurious_ints++;
    return CYGNUM_HAL_INTERRUPT_unused; // This shouldn't happen!
}
=========== code snippet ==============================================

This will tell you if a) you're getting any interrupts at all, and b) what
interrupts are present.  Caution: if things are really broken, this may generate
a number of outputs - you might have to reset the board manually to stop them.

On 12-Jun-00 Alfredo Knecht wrote:
> Dear list,
> 
> At 05:38 11.6.00 -0600, you wrote:
>>
>>On 11-Jun-00 Alfredo Knecht wrote:
>>> Dear All,
>>> 
>>> Thread switching is not working.
>>> I am using an off-the-shelf configuration for ARM EDB7111-2, with the
>>> GDB_module stub on the board.
>>> Specifically, I tested with lcd_test.c, and kthread1.c.
>>> Only the first thread (in cyg_thread_create() calling order) is ever
> executed.
>>> A call to cyg_thread_delay() blocks, and cyg_thread_yield() does not cause
>>> rescheduling.
>>> Fidgeting with priorities does not help, either.
>>> Generally, single-thread code works.
>>> Must be that thread switching stays disabled in eCos, but since I am using
>>> a "standard" configuration, I would like to have a second opinion before
>>> embarking on a deep dive.
>>> 
>>
>>Thread switching should work on this and all platforms.
>>
>>Have you tried any of the standard tests and/or examples?  A good one to
>>try is the 'bin_sem2' test in the kernel.  This is an adaptation of the
>>classic dining philosophers and definitely relies on thread switching to
>>work properly.  On Linux, one would build/run this test like this:
>>
>>  # ecosconfig new edb7211
>>  # ecosconfig tree
>>  # make tests
>>  # arm-elf-gdb install/tests/kernel/VERSION/tests/bin_sem2
>>     ... etc.
>>
>>
> 
> I am puzzled, and probably doing something wrong. bin_sem2 hangs (see
> below), as do the simpler standard tests like kthread1.
> After deselecting RTC support, I compiled intr.c (which attaches its own
> rtc handler), but this one hangs, too.
> In lcd_test (a single-thread test) the cyg_thread_delay() call never
> returns; commenting out the calls to cyg_thread_delay() helps, but this
> amounts to not using ecos threading services at all.
> The counter/timer 2 is working, its interrupt unmasked. Counting all
> interrupts (in hal_IRQ_handler()) consistently brings a grand total of 2
> before the board freezes.
> Thanks for your help.
> Alfredo
> ----------------------
> Working directory /j/p1_install/tests/kernel/v1_3_1/tests.
> 
> (gdb) target remote com1
> Remote debugging using com1
> 0xe0001750 in ?? ()
> 
> (gdb) load bin_sem2.exe
> Loading section .rom_vectors, size 0x60 lma 0x8000
> Loading section .text, size 0x96a8 lma 0x8060
> Loading section .rodata, size 0x1bc3 lma 0x11708
> Loading section .data, size 0x418 lma 0x132cc
> Start address 0x8060 , load size 46819
> Transfer rate: 26753 bits/sec, 302 bytes/write.
> 
> (gdb) cont
> Continuing.
> 
> --------------------------
> 
> ************************************************************************
> Alfredo Knecht       Fax  ++41 91 610 8970          Tel ++41 91 610 8960
> SUPSI-ICIMSI         aknecht@cimsi.cim.ch        http://www.cimsi.cim.ch
> 
> Istituto CIM della Svizzera italiana              CH-6928 Manno (Lugano)
> ************************************************************************
>