MVME2304 Exception 3

[Paul D Jines]

> Paul - can you, please, provide a full log of
> all messages printed (from PPCbug after powerup
> through GeSys reporting exception 3 (including the
> register and stack dumps) ? With this information,
> I'll be able to help you.

It's on it's way via email.  Thanks!

For malloc/sbrk, I tried as a cheap test to modify the call
to bsp_libc_init (in bspstart.c) to pass a heap_size of just
under 16MB (replacing  BSP_mem_size with 16MB in the heap_size assignment).
The heap_start and use sbrk parameters were left the same.  Would this
accomplish the
same thing as a test?  If so, then the results for hello.exe
are: worked the first time, (reset), exception 3, (reset),
exception 3.

Paul

>>
>> Since you have >32M of memory, I want to remind
>> you of the usual problem: gcc, by default, does
>> not generate far calls and hence run-time loading
>> of code fails if the loaded objects end up
>> (CEXP uses heap memory for all segments) more
>> than 32M apart from code they reference.
>> As a work around, I can provide you with a patch
>> that restricts memory to 32M at startup. The
>> patch implements a trivial 'sbrk()', so additional
>> memory becomes available after you use up the first
>> 32M. This way, you can load all of your code
>> (EPICS application) first (i.e. before allocating
>> large amounts of memory). The same problem exists
>> with vxWorks, BTW...

>If this does in fact turn our to be the problem, then
>it may be as simple as you say.  With a functional sbrk()
>in the motorola_shared BSP and making sure >RTEMS_Malloc_Initialize()
>is passed a smaller "length" and the rest of memory as
>the "sbrk_amount".

>Then you can malloc() memory until you run out of low RAM
>and malloc() will automatically call sbrk() with the >sbrk_amount.