[ECOS] LPC2XXX: Spurious Interrupts Issue
Gary Thomas
gary@mlbassoc.com
Sat Feb 3 13:53:00 GMT 2007
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
More information about the Ecos-discuss
mailing list