hello world debug info

[Simon Dismo]

Hi Brendan,
 It seems to me that you have some problem with your console driver so that 
no text is printed. The application will then exit properly and go to 
'bsp_cleanup'. If your 'bsp_cleanup' routine is empty (as Monkmans was)
there will be another attempt to boot up. You probably should put a 
'trap' in the 'bsp_cleanup' routine to trap back into mpc8bug so that
you will be aware that you have exited from RTEMS.

My 'bsp_cleanup' for a Motorola FADS system looks like:

void bsp_cleanup( void )
{
  /*--------------------------------------------------------*/
  /* Load gpr11 with 0x0BCE0BCE and trap back into debugger */
  /*--------------------------------------------------------*/
  /* simon */

  asm volatile("addis 9,0,0x0BCE");
  asm volatile("addi 11,9,0x0BCE");
  asm volatile("tw 31,0,0"); 
}

This routine should of course be replaced with something more 
intelligent for a real product where you have no debugger attached
(or leave it empty to just reboot RTEMS).

You should check to see if your application ever gets to 'Init' or
whatever your hello-world application task function is called.

Setting a breakpoint on rtems_fatal_error_occured is also a good
idea.

The 'text not printing problem' is usually a consequence of a
missconfigured clib. If you are using Monkmans code and any version
of RTEMS 4 (beta) then you must have the corresponding patches 
for Newlib-1.8.0 (from OAR that is).

Hope this will give you some help.

Best Regards
Simon Dismo 

> From: Brendan Simon <brendan at dgs.monash.edu.au>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: rtems-list <rtems-list at oarcorp.com>, Jay Monkman <jmonkman at frasca.com>
> Subject: hello world debug info
> Content-Transfer-Encoding: 7bit
> 
> I've debugged hello world running to the following point.  I have put
> break points in critical parts of the code and the following was
> observed.
> 
> set breakpoint at bssclr in dlentry.S
> set breakpoint at boot_card in .../libbsp/shared/main.c
> set breakpoint at rtems_initialize_executive_early in
> .../sapi/src/exinit.c
> set breakpoint at rtems_initialize_executive_late in
> .../sapi/src/exinit.c
> 
> go start
> 
> break at bssclr
> break at boot_card
> break at rtems_initialize_executive_early
> break at rtems_initialize_executive_late
> break at boot_card
> break at rtems_initialize_executive_early
> break at rtems_initialize_executive_late
> break at boot_card
> break at rtems_initialize_executive_early
> break at rtems_initialize_executive_late
> break at boot_card
> break at rtems_initialize_executive_early
> break at rtems_initialize_executive_late
> 
> as can be seen, boot_card is being continually called for some reason.
> It seems when boot_card returns back to the code in dlentry.S it then
> calls boot_card again.  I'm not sure why it does that because I can't
> see any code in dlentry.S that continually calls boot_card (unless there
> is some fancy way to do it via the link register).
> 
> If I put a breakpoint on main() it never breaks.  But
> rtems_initialize_executive_late is only called from within main() so I'm
> not sure how it gets invoked.  Maybe main() has been optimized and
> compiled inline ???
> 
> What part of the code actually starts/runs the kernel ??
> It either never gets called or for some reason terminates and normal
> flow continues.
> 
> Please help if you have any ideas.
> 
> Brendan Simon.
> 
>