Debugging broken BSP suggestions?

[James Fitzsimons]

Hi all,

I've made a bit of progress tracking down the problem. I wrote an
implementation for printk and managed to isolate the issue.

It is dying in the following funciton in cpu.c:

void _CPU_Install_interrupt_stack( void )
{
#if ( M68K_HAS_SEPARATE_STACKS == 1 )
  void *isp = _CPU_Interrupt_stack_high;

  asm volatile ( "movec %0,%%isp" : "=r" (isp) : "0" (isp) );
#endif
}

Looking in m68k.h, M68K_HAS_SEPARATE_STACKS should be false for a mcpu32
target. What am I missing?

Is it something to do with RTEMS_CPU or RTEMS_CPU_FAMILY not being set
correctly?

My RTEMS version is 4.10.2 and I'm using eclipse with the RTEMS plugin.

Feels like I'm close now, appreciate any pointers on these last details.

Cheers,
James


On 7 March 2014 07:41, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:

>
> On 3/6/2014 11:19 AM, Gedare Bloom wrote:
> > On Thu, Mar 6, 2014 at 5:37 AM, James Fitzsimons
> > <james.fitzsimons at gmail.com> wrote:
> >> Hi all,
> >>
> >> I'm trying to get an old bsp working - the mrm332 bsp for a 68332
> target. I
> >> know it's old technology but I have one of these boards and it will be a
> >> good fit for a project I want to do.
> >>
> >> Unfortunately I don't think the mrm332 bsp can every have been in a
> working
> >> state, or at least it isn't anymore.
> >>
> > What version of RTEMS is this BSP on?
> >
> >> I managed to get it kind of working by using the RAM linker script which
> >> just dumps everything into RAM, of course you can only run your program
> once
> >> and then you have to reload because the .data section gets hosed.
> >>
> >> I think I'm close to a linker script to run out of ROM, but it seems to
> be
> >> failing when it gets to bsp_get_work_area in bootcard.c. All I end up
> with
> >> is garbage at the console. I've verified it works up to here by
> switching on
> >> one of the onboard LED's just prior to the call to bsp_get_work_area.
> I've
> >> also examined the memory (flash and RAM) and it all looks pretty good.
> >> Moving the LED code to just after the call to bsp_get_work_area doesn't
> >> work.
> >>
> > The most likely case is that the work area is overlapping with other
> > memory sections in your linker script. The work area and program heap
> > need to be well-defined regions that do not overlap with anything
> > else, otherwise the initialization of those heaps will wipe out
> > whatever memory they overlap.
> >
> >> I've gone over my linker script a dozen times. Anyone have any
> suggestions
> >> as to how to debug this problem?
> >>
> > Try to find the bounds on the program heap and the work space. See
> > what the start/end addresses are and whether they are overlapping with
> > anything else in memory.
> If on the head, this is a likely candidate. AFAIK this BSP has not been
> tested since
> we moved to the common code for initializing memory. A simple bug in memory
> layout during the adjustment would do this.
> > Good luck,
> > Gedare
> >
> >> Many thanks!
> >> James Fitzsimons
> >>
> >> _______________________________________________
> >> rtems-users mailing list
> >> rtems-users at rtems.org
> >> http://www.rtems.org/mailman/listinfo/rtems-users
> >>
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.org
> > http://www.rtems.org/mailman/listinfo/rtems-users
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20140309/6b4025a3/attachment-0001.html>