Ticker problem on ppc405 - FIXED

[Joel Sherrill <joel@OARcorp.com>]

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
> #else
>     do that way
> #end
> 
> 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?

--joel


> -gene
> 
> 
> 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 
>> powerpc-rtems-gcc.)
>>
>> If anyone has an understanding of this code I would appreciate any 
>> suggestions as to what is going wrong.
>>
>> Thanks,
>> -gene
>> 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