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

[Sergei Gavrikov <sergei.gavrikov@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

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

[-- Attachment #2: lpc2xxx_misc.c.patch --]
[-- Type: text/x-diff, Size: 1097 bytes --]

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 + 


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

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