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]

RE: interrupt/virtual vectors confusion


>Is Blinky an eCos RAM program? If so it should of taken over the
>interrupt vectors from Redboot. Redboot should no longer be active
>unless blinky actually calls into Redboot via the virtual vectors.

Blinky is just a standalone program I decided to use as a test. The only
change I've made to it to make it run is to link it directly into free
ram so that I can run it after having loaded it from Redboot (with a
load -r -m ymodem -b 0x20005b68). 
The reason I know that Redboot is handling (or at least that Redboot
code is being called) the IRQ is that I put while(1){flash an led every
second} at the top of hal_IRQ_handler and that it gets stuck there when
I run Blinky.

>The vectors will be in RAM, not ROM. On ARM architectures what
>normally happens is that at startup ROM is mapped to address 0x0. Once
>the program is running is remaps the memory so that ROM is moved to
>higher addresses and RAM is mapped to address 0x0. The vectors can
>then be changed by the application. 

Hmm. I know that my board maps Flash ROM (0x40000000) to 0x00000000. It
also puts something in RAM because when I run Redboot I get the 
	RAM: 0x20000000-0x20010000, [0x20005b68-0x20010000] available 
Message. On an interrupt the PC goes to 0x00000018 which is where
Redboot's vector sits (having been mapped by the board) and that's why
(I think) the Redboot ends up handling my interrupts. Do you mean that
Redboot also remaps it's vector to 0x20000000? When you say "the
program...remaps the memory" is the program Redboot or your own program?


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


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]