Hard reset during RTEMS multiprocessing initialization

[John Harwell]

Hello,

I'm currently working on getting RTEMS 4.10 up and running on the LEON3, 
utilizing its multiprocessing functionality. I have a bootstrap that 
runs from address 0x0, initializes and checks memory, and then copies 
each of two RTEMS multiprocessing node images to addresses 0x40010000 
and 0x40080000, with the shared memory location being between 0x40000000 
and 0x40001000. The issue I am running into is that when both CPUs come 
up and start executing the RTEMS images, CPU 0 (which is RTEMS node 1) 
always causes a hard reset during initialization, which then causes the 
board to begin execution again from address 0x0, thus repeating the 
bootstrap, resulting in a boot loop. As far as I understand, RTEMS can 
cause a software trap 0x80 via "ta 0x0", but how does it cause a hard 
reset trap? Or rather, what in RTEMS initialization would have the 
potential to cause such a thing?

If I step through the RTEMS initialization functions manually in 
assembly using GRMON, I can get things up and running; that is, both 
Init()s fire and both nodes come up. The problem function at a high 
level is bsp_pretasking_hook(), and within that 
bsp_spurious_initialize(), which goes through and installs trap 
handlers. If I manually step through the for loop that installs the 
handlers in bsp_spurious_initialize(), and then let things run normally 
from there, everything is ok. If I break right before 
bsp_spurious_initialize(), and then set a breakpoint for after the 
function returns, and try to let bsp_spurious_initialize() run normally, 
the hard reset occurs somewhere in the function body/for loop.

Any idea of what is going on?

Thanks,

-- 
John Harwell
Engineer
High Reliability Software Section
Communications and Embedded Systems Department

john.harwell at swri.org
Office: 210-522-5965
Southwest Research Institute (SwRI)
6220 Culebra Road, San Antonio, TX 78238-5166