Ticker problem on ppc405 - FIXED

[Smith, Gene]

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.

-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.