RE: [ECOS] semaphore bug??

RE: [ECOS] semaphore bug??

[Geoff Patch]

Hi Folks,

> I don't think you can post to a semaphore from an ISR.  You'll
> have to run a DSR and do it there.  There's a table in the eCos
> Reference Manual (Device Driver Interface to the Kernel) that
> shows what functions may be called from an ISR.  About the only
> thing you can do is ack/mask/unmask interrupts and run a DSR.

This is correct, and I recall other postings to the list about this issue. 
 It's obviously a fairly common misconception. I come from a pSOS 
background, where it is possible to post a semaphore in an ISR, and I also 
spent a bad week stumbling over this exact issue .

Could I suggest to the eCos team that an explicit statement of *exactly* 
what can and cannot be done in an ISR be inserted into the "eCos Interrupt 
Model" section of the Reference manual? I'm sure that this would help a lot 
of newbies (like me) retain their sanity. :-)

And while I'm writing, I'd like to say that I think eCos is a great piece 
of gear. Hats off to you guys.


Cheers

Geoff

------------------------------
Geoff Patch
Senior Software Engineer
CEA Technologies
Canberra Australia
02-6213 0141

Re: [ECOS] semaphore bug??

[Andrew Lunn]

On Wed, Aug 15, 2001 at 11:49:32AM +1000, Geoff Patch wrote:
> 
> Hi Folks,
> 
> > I don't think you can post to a semaphore from an ISR.  You'll
> > have to run a DSR and do it there.  There's a table in the eCos
> > Reference Manual (Device Driver Interface to the Kernel) that
> > shows what functions may be called from an ISR.  About the only
> > thing you can do is ack/mask/unmask interrupts and run a DSR.
> 
> This is correct, and I recall other postings to the list about this issue. 
>  It's obviously a fairly common misconception.

How about adding an assertion check to semaphores and mutex etc. If
they are called from within an ISR throw an assertion.

        Andrew

Re: [ECOS] semaphore bug??

[Jonathan Larmour]

Andrew Lunn wrote:
> 
> On Wed, Aug 15, 2001 at 11:49:32AM +1000, Geoff Patch wrote:
> >
> > Hi Folks,
> >
> > > I don't think you can post to a semaphore from an ISR.  You'll
> > > have to run a DSR and do it there.  There's a table in the eCos
> > > Reference Manual (Device Driver Interface to the Kernel) that
> > > shows what functions may be called from an ISR.  About the only
> > > thing you can do is ack/mask/unmask interrupts and run a DSR.
> >
> > This is correct, and I recall other postings to the list about this issue.
> >  It's obviously a fairly common misconception.
> 
> How about adding an assertion check to semaphores and mutex etc. If
> they are called from within an ISR throw an assertion.

Unfortunately there is no portable way to determine if you are in an ISR.
Instead you would have to set a HAL level boolean in the interrupt VSR
before calling the ISR. And if the ISR, for whatever reason, doesn't exit
by returning, it would all go very wrong.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] semaphore bug??

[Grant Edwards]

On Tue, Aug 14, 2001 at 03:21:05PM -0400, Warren Jasper wrote:
> 
> I have written an application that blocks on a semaphore.  When
> an interrupt is generated, the semaphore is released, and the
> program **should** continue.  Here is a snippit:
> 
> /* synchronization semaphore */
> static  cyg_sem_t dma_store_done_sem;
> 
> // I then initialize the semaphore to 0 and register the isr ...
> 
> static cyg_uint32 dma_store_done_isr(cyg_vector_t vector, cyg_addrword_t data, cyg_addrword_t *regs)
> {
>   CYG_WORD32 dspctl;
> 
>   //diag_printf("Entered dma_store_done_isr.  vector = %d Releasing semaphore.\n", vector);
>   cyg_interrupt_acknowledge(vector);
>   /* put the DMA into reset  */
>   HAL_READ_UINT32_MCB(DSPCTL, dspctl);
>   dspctl |= ResetDMA;
>   HAL_WRITE_UINT32_MCB(DSPCTL, dspctl);
>   cyg_semaphore_post(&dma_store_done_sem);

I don't think you can post to a semaphore from an ISR.  You'll
have to run a DSR and do it there.  There's a table in the eCos
Reference Manual (Device Driver Interface to the Kernel) that
shows what functions may be called from an ISR.  About the only
thing you can do is ack/mask/unmask interrupts and run a DSR.

-- 
Grant Edwards
grante@visi.com

[ECOS] semaphore bug??

[Warren Jasper]

I have written an application that blocks on a semaphore.  When an interrupt is generated, the
semaphore is released, and the program **should** continue.  Here is a snippit:

/* synchronization semaphore */
static  cyg_sem_t dma_store_done_sem;

// I then initialize the semaphore to 0 and register the isr ...

static cyg_uint32 dma_store_done_isr(cyg_vector_t vector, cyg_addrword_t data, cyg_addrword_t *regs)
{
  CYG_WORD32 dspctl;

  //diag_printf("Entered dma_store_done_isr.  vector = %d Releasing semaphore.\n", vector);
  cyg_interrupt_acknowledge(vector);
  /* put the DMA into reset  */
  HAL_READ_UINT32_MCB(DSPCTL, dspctl);
  dspctl |= ResetDMA;
  HAL_WRITE_UINT32_MCB(DSPCTL, dspctl);
  cyg_semaphore_post(&dma_store_done_sem);
  return CYG_ISR_HANDLED;
}

void StoreCoreData( CYG_WORD32 coreAddr, CYG_WORD32 *addr, int nWords )
{
  cyg_count32 value;
  CYG_WORD32 dspctl;
  cyg_mutex_lock(&dma_store_imem_block);

 ... do stuff ...

  if (!cyg_semaphore_timed_wait(&dma_store_done_sem, cyg_current_time() + 10) ) {
    printf("StoreCoreData: semaphore dma_store_done_sem timed out.\n");
    cyg_semaphore_peek(&dma_store_done_sem, &value);
    printf("StoreCoreData: semaphore value = %d\n", value);
  }
  cyg_mutex_unlock(&dma_store_imem_block);
  return;
}

I have checked, and the interrupt is being sent,  and   cyg_semaphore_post() is
being called.  On the second time I try this, I get:

(gdb) c
Continuing.
StoreCoreData: semaphore dma_store_done_sem timed out.
StoreCoreData: semaphore value = 1

How is it possible that the semaphore is blocked when the value is 1?
If I don't put use cyg_semaphore_timed_wait, it blocks forever.  I have checked
and the value of the semaphore just after    cyg_semaphore_post() in the isr
is one.

Any suggestions?

	-- Warren

Warren J. Jasper
wjasper@tx.ncsu.edu