Re: [ECOS] Can excessive/intensive serial flow cause stack overflow?

[Sergei Gavrikov <sergei dot gavrikov at gmail dot com>]

Alexandre wrote:
> On Thu, Jul 3, 2008 at 5:39 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > Duh... Didn't read the message correctly, so missed the obvious problem....
> >
> > I thought vector, then the problem is priority.....
> >
> > This is easy to explain. The actual serial driver is in
> > /packages/devs/serial/generic/16x5x/current/src.
> >
> > It registers the interrupt handler with:
> >
> >        cyg_drv_interrupt_create(ser_chan->int_num,
> >                                 CYG_IO_SERIAL_GENERIC_16X5X_INT_PRIORITY,
> >                                 (cyg_addrword_t)chan,
> >                                 pc_serial_ISR,
> >                                 pc_serial_DSR,
> >                                 &ser_chan->serial_interrupt_handle,
> >                                 &ser_chan->serial_interrupt);
> >
> > The priority is hard coded for all serial devices as 4.
> >
> > You can sort of override this. The same file says:
> >
> > #ifndef CYG_IO_SERIAL_GENERIC_16X5X_INT_PRIORITY
> > # define CYG_IO_SERIAL_GENERIC_16X5X_INT_PRIORITY 4
> > #endif
> >
> > but you don't appear to be able to override it per device, just for
> > all devices. So i think you are not going to be able to benefit from
> > vectored interrupts and will have to use a priority of 16. Or you need
> > to have the serial driver to allow you to specify a priority level per
> > device.
> >
> > Humm, actually, you could do something a little horrible like:
> >
> > #define  CYG_IO_SERIAL_GENERIC_16X5X_INT_PRIORITY \
> >         (ser_chan->int_num == CYGNUM_HAL_INTERRUPT_UART0 ? 4 : 5)
> >
> > in arm_lpc2xxx_ser.inl
> >
> >         Andrew
>
> That does the trick.
> The program stops there (after cyg_user_start(), some scheduler, clock
> and thread work) :

If I remember, in a past I did catch same asserts on LPC2XXX UARTS

ASSERT FAIL: (1) lpc2xxx_misc.c[472]hal_interrupt_set_level() Priority
already used by another vector

So, I just dirty tweaked the lpc2xxx_misc.c to shift priority to next
free slot. I found that my patch. Try to apply the patch and rebuild
eCos build tree. Today, I have no LPC2XXX hardware to test it.

Sergei
diff -ur A/hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.c B/hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.c
--- A/hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.c
+++ B/hal/arm/lpc2xxx/var/current/src/lpc2xxx_misc.c
@@ -462,12 +462,18 @@
     //
     if (level < 16)
     {
+        int i;
         cyg_uint32 addr_offset =  level << 2;
         cyg_uint32 reg_val;
         
-        HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_VIC_BASE + 
-                        CYGARC_HAL_LPC2XXX_REG_VICVECTCNTL0 + 
-                        addr_offset, reg_val);
+        for (i = level; i < 16; i++) {
+            addr_offset = i << 2;
+            HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_VIC_BASE +
+                            CYGARC_HAL_LPC2XXX_REG_VICVECTCNTL0 +
+                            addr_offset, reg_val);
+            if ((reg_val == 0) || (reg_val == (vector | 0x20)))
+                break;
+        }
         CYG_ASSERT((reg_val == 0) || (reg_val == (vector | 0x20)), 
                    "Priority already used by another vector");
         HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_VIC_BASE + 

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss