This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Problem with DSRs
I figured out that the problem was that I was not declaring the ISR
interrupt and ISR handle variables as 'statics'. Since I declared them
inside of an initialization function, they were 'autos', so when it was
time to call a DSR for example, the DSR address part of the interrupt
objects had already been overwritten with nonrelated data. Instead of
posting the correct DSR address, a garbage address was being posted
which was entirely out of range.
Miguel J. Vega
FEGI C&DH Team
University of Michigan
On Jul 27, 2004 Miguel J. Vega wrote:
| Hi everyone,
|
| I have been having trouble with with a DSR. I will describe how my set up
| is so far. The serial module on our board is currently configured to
| signal an interrupt. There are two things that can cause the interrupt so
| I made an arbitration ISR that decides what the actual cause was and upon
| making the decision, calls the appropriate ISR. This method has worked
| fine so far.
|
| I have decided to have additional code in DSRs for each ISR except the
| arbitration ISR. Of course, I have the ISRs return CYG_ISR_CALL_DSR and
| when I create the interrupts with cyg_interrupt_create(...), I include the
| address of the DSRs.
|
| When I run my code and have an interrupt be caused, the ISR code executes
| and the DSR code executes, but then I get the following:
| $T0bthread:00000002;40:1111000e;01:00c1c100;#a5
|
| I also used GDB to step through the code, and I find out that the code
| hangs at the rfi powerpc instruction.
|
|
| Miguel J. Vega
| FEGI C&DH Team
| University of Michigan
|
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss