Re: [ECOS] LPC2XXX: Spurious Interrupts Issue

[Gary Thomas <gary at mlbassoc dot com>]

wang cui wrote:
> Fine for me.
> Does eCos maintainer read this? Is it worth to patch this into CVS?

Yes.  Send a proposed patch to ecos-patches@sourceware.org and
we'll review it.

> 
> 
>> From: Sergei Gavrikov <w3sg@SoftHome.net>
>> To: wang cui <iucgnaw@msn.com>
>> CC: w3sg@SoftHome.net, ecos-discuss@ecos.sourceware.org
>> Subject: Re: [ECOS] LPC2XXX: Spurious Interrupts Issue
>> Date: Sat, 3 Feb 2007 00:39:19 +0200 (EET)
>>
>>
>>
>> On Fri, 2 Feb 2007, wang cui wrote:
>>
>>>> Thanks, I brief look at the patch. You fix the LPC2XX vector table.
>>>> ...
>>> I raised discrssion about this issue serval months ago:
>>> http://sources.redhat.com/ml/ecos-discuss/2006-08/msg00225.html I
>>> think Gary's advice is a good solution, and I just havn't done it yet.
>>> So still leave this piece of ugly code here. :-)
>>
>>> As I need burn the image into off-chip flash, so the ARM_VECTOR_0x14
>>> should be set correctly without rely on burner.  Of cource, your
>>> suggestion of do it with a script in "make" process is good, but how
>>> about Redboot(I don't think modify Redboot's make process is
>>> resonable)? And other newbies may be very hard to catch this
>>> problem(because they can't find any info from CVS except search
>>> maillist).
>>>
>>> So I suggest to solve it in Gary's way. We add a CDL interface in ARM
>>> arch package to allow user configure ARM_VECTOR_0x14, then add a CDL
>>> implemention in LPC2XXX's variant package.
>>>
>>> What is your opinion? Hope we can solve this issue.
>>
>> I did miss that issue. I read, thanks, So, there is an inclusion
>> of the <pkgconf/hal.h> at first in vector.S, therefore, to wrap
>> 'unused' vector at 0x14 (as Gary suggested) by that condition in
>> vector.S would be enough for everybody
>>
>>     #ifdef CYGSEM_HAL_ARM_VECTOR_0x14
>>             .word   CYGSEM_HAL_ARM_VECTOR_0x14
>>     #else
>>             .word   0
>>     #endif
>>
>> IMO, such a CDL option would be introduced in variant, that will
>> be in cyg/hal/hal_arm_lpc2xxx.h (= hal.h) then
>>
>>     cdl_option CYGSEM_HAL_ARM_VECTOR_0x14 {
>>         display    "Default value of unused vector"
>>         flavor     data
>>         default_value <today value>
>>         description "
>>            In order to detect if a valid program is present, every
>>            user program must have a program signature. This signature
>>            is a word-wide number that is stored in the unused
>>            location in the ARM7 vector table at 0x00000014. The
>>            program signature is the two's compliment of the checksum
>>            of the ARM vector table."
>>     }
>>
>> Gary pointed out then
>>
>>     Gary> The other problem I see is that this may not
>>     Gary> be constant as you have made it.  Would it not
>>     Gary> change if the various other vector handlers move
>>     Gary> around, i.e.  if 'abort_data' changes address,
>>     Gary> etc?  Would it not need to be [re]calculated?
>>
>> Well, we know that <cyg/hal/hal_platform_setup.h> include itself in
>> vector.S then (after hal.h), therefore, the target specific assembler
>> code would contain a commented note (at EOF), like a memory stick
>>
>>     #if 0
>>     #undef CYGSEM_HAL_ARM_VECTOR_0x14
>>     // In order to detect if a valid program is present,
>>     // every user program must have a program signature. This
>>     // signature is a word-wide number that is stored
>>     // in the unused location in the ARM7 vector table
>>     // at 0x00000014. The program signature is the two's
>>     // compliment of the checksum of the ARM vector table.
>>     #define CYSEM_HAL_ARM_VECTOR_0x14 <tommorow value>
>>     #endif
>>
>> In this case an advanced user would be overwrite that then without
>> reconfigure build tree.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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