Ticker problem on ppc405 - FIXED
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Tue Oct 19 11:08:34 UTC 2004
Smith, Gene wrote:
> Figure out what the problem is but not why or how to correctly fix it.
> The problem was due statements like this for selecting code:
> #if (PPC_USE_SPRG)
> do this way
> do that way
> In file old_exception_processing/cpu.c "do that way" is selected, while
> in old_exception_processing/irq_stub.S "do this way" is selected. The
> conflict resulted in some bad memory accesses. I don't see anywhere
> that PPC_USE_SPRG is explicitly defined in the code except under
> build-rtems there is a automatically generated file bspopts.h that contains
> #define PPC_USE_SPRG 1
> But the file that (I think) controls this, bspopts.h.in, contains
> #undef PPC_USE_SPRG
> The kluge fix was to just add
> #define PPC_USE_SPRG 0
> in irq_stub.S so both files generate "do that way" code.
> Anyhow, ticker now runs.
Ralf.. how is this happening? This is one of those
macros from the BSP's configure.ac. bspopts.h should
have it as a 1 if I am reading the configure code correctly.
Gene.. the installed bspopts.h has it undef'ed?
Where does the cpu.c get its define?
> Gene Smith wrote, On 10/17/2004 11:46 PM:
>> I have tried to run the ticker example with no changes. I can see that
>> it installs a interrupt handler for a Programmable Interval Timer
>> (PIT) called from the typical location 0x1000 (with EVPR set to 0).
>> However, when it actually runs I rarely see a vector to 0x1000. The
>> first interrupt that occurs is usually to location 0x200 which is a
>> machine check (bus error). When the machine check tries to branch to
>> its actual handler (in _ISR_Handler) it looks like it sees a zero
>> pointer which in turn causes a "Program" interrupt at location 0x700,
>> which in turn causes a branch to zero and another Program interrupt,
>> ad infinitum.
>> I only see explicit handlers being installed for the UART (an external
>> interrupt which begins at location 0x500) and the PIT interrupt off of
>> location 0x1000. I don't see any real handler installed for Machine
>> Check or Program. I would assume these might be caught by a default
>> spurious handler but the "blrl" at irq_stub.S:150 branches to location
>> 0 which just results in another Program exception.
>> The first Machine Check interrupt that gets the whole process going
>> stores in register SRR2 the value 0x5938 which is supposed to be the
>> bus error location. Location 0x5938 is actually an instruction in
>> irq_stub.S (part of _IRQ_Handler) but I don't see a problem there and
>> putting a breakpoint before location 0x5938 never hits before the
>> first Machine Check at 0x200.
>> One other observation: In old_exception_processing/cpu.c:508 where the
>> actual stwu_r1 value is compared to a template value they do appear to
>> be equal but for some reason the else condition is taken and
>> *old_handler is set to zero. This appears to be a possible compiler
>> error. (I am checking this with no optimization -O0 in
>> If anyone has an understanding of this code I would appreciate any
>> suggestions as to what is going wrong.
>> P/S: I can step through the code and see what is happening using the
>> Macraigor JTAG debugger with gdb/insight.
>> Please reply to list.
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users