[ECOS] LPC2XXX: Spurious Interrupts Issue

wang cui iucgnaw@msn.com
Sat Feb 3 01:31:00 GMT 2007


Fine for me.
Does eCos maintainer read this? Is it worth to patch this into CVS?


>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.
>
>
>Sergei
>
>
>--
>Before posting, please read the FAQ: 
>http://ecos.sourceware.org/fom/ecos
>and search the list archive: 
>http://ecos.sourceware.org/ml/ecos-discuss
>

_________________________________________________________________
Ãâ·ÑÏÂÔØ MSN Explorer:   http://explorer.msn.com/lccn/  


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



More information about the Ecos-discuss mailing list