This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

interrupt/virtual vectors confusion


Hello,

 

I am a bit confused as to how(or whether) to use virtual vectors for
interrupt handling. My situation is as follows:

I have ported Redboot to run on an ST STR710FZ2 eval board and it is
running fine. 

I load a separate binary (good old Blinky for now as a test) which I've
linked to sit in the RAM area that is left free by Redboot (for me
currently 0x20005b68).

Blinky runs up to the point where an IRQ fires and the interrupt is
caught and serviced by Redboot's IRQ and handle_IRQ_or_FIQ functions
defined in vectors.S. That is not what I want.

What I want to do is to tell Redboot that I want to handle my own
exceptions, ideally by jumping to my own vector table. 

The trouble is that, because Redboot runs from ROM, I can't, from Blinky
or any other RAM resident program, change the Redboot vector to jump to
my own ISRs. 

I understand that there is a way of telling Redboot to jump to a second
table (virtual vector table?) which can be changed to point to whatever
you want, but I am not sure how to set this up.

In vectors.S I can see a fixed_vectors section which defines a
hal_vsr_table (as 8 nulled longs), but the eCos documentation states
that the ARM (which is what I'm using) doesn't use the hal_vsr_table.

 

Has anyone had a similar problem or know of a good way of approaching
this?

 

Thanks in advance,

 

m@

--------------------------------------------------------------------------------


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

If you received this in error, please contact the sender or postmaster (postmaster@hanoverdisplays.com) and delete the material from any computer.

Although we routinely screen for viruses, addressees should check this e-mail and any attachment for viruses. We make no warranty as to absence of viruses in this e-mail or any attachments.

Our Company's email policy is to permit incidental personal use. If this email is of a personal nature, it must not be relied upon as expressing the views or opinions of the company.

Visit out website at www.hanoverdisplays.com



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]