[ECOS] LPC2XXX: Spurious Interrupts Issue

[Sergei Gavrikov]

On Sat, 3 Feb 2007, Gary Thomas wrote:

> 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.

They haven't to do such things for us. We have to do it. There is an evil
for me in eCos world :) That is a copyright assignment.  The $0.02 patches
(a few lines of code) are welcome to CVS without any printer's sheets.

I brief look at my evening letter. It looks like that I have to read again
the Bart's 'The eCos Component Writer's Guide'. I have a doubt about
the name CYGSEM_HAL_ARM_VECTOR_0x14. It seems such a name is correct
for boolean values only. And CYGNUM_HAL_ARM_VECTOR_0x14 is a suitable
for numeric values (our case). Gary did suggest to name it CYGINT_ ...
But if I didn't forget that prefix is suitable for interfaces.

Gary, what is your view about CYG naming?

Well, anybody from us has to make the final patch, test it on the LPC
targets and then send it to ecos-patches list.  If they will accept it,
that will be okay for us.

Sergei

>>
>>
>>> 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
>

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