Changes between Version 23 and Version 24 of TBR/Review/Debugging/Start


Ignore:
Timestamp:
Nov 20, 2018, 12:01:26 AM (5 months ago)
Author:
Joel Sherrill
Comment:

Remove more questionable content

Legend:

Unmodified
Added
Removed
Modified
  • TBR/Review/Debugging/Start

    v23 v24  
    1414
    1515 * PowerPC MPC5xx and MPC8xx use BDM, while the rest of the PowerPC family uses various kinds of JTAG interfaces.
     16
    1617= Coldfire and M683xx BDM =
    1718
     
    2425
    2526The latest version of the BDM software use a GDB server program and allows the use of the standard M68K GDB tool provided in the RTEMS binary tools packages.
    26 = Debugging a BSP =
    2727
    28 
    29 To test a BSP you need an application. The samples and tests provide a proven set of applications that allow you to test your BSP. Select a sample application such as the '''Hello World''' to try first, then move to an application that uses more interrupt sources.
    30 
    31 The following is a list of debugging tools and setups that we recommended. Time spent on this will be rewarded further into the project:
    32 
    33  * Try to create a working debugger environment for the target hardware. The GNU debugger, GDB, supports a number of different ways to connect to a target. The interface can be a simple serial port using a [wiki:Debugging/GdbSerialMonitor GdbSerialMonitor], or an expensive TCP/IP type hardware probe.
    34 
    35  * If your target processor supports a simulator it is recommended you learn how to use it. It will give you a stable debugging enviroment.
    36 
    37  * Implement a ''printk'' interface in your BSP. For target hardware that does not have a video interface the ''printk'' outputs to a serial port. The driver is normally a simple polled UART driver.
    38 
    39  * Use the [wiki:TBR/UserManual/Capture_Engine Capture Engine] to aid the debugging and verfication of your real-time design.
    40 
    41 
    42 = BSP rtems_initialize_executive_late call dies =
    43 
    44 
    45 Your target is booting and the BSP is initialising but a call to ''rtems_initialize_executive_late'' results in an exception, or the target locking up. This can be due to a few reasons that you will need to work through.
    46 
    47  * The memory map is not correct. RTEMS use the [wiki:WorkSpace WorkSpace] to create the initialization task, it's stack, the interrupt stack, plus more. If the [wiki:WorkSpace WorkSpace] is wrong the target will die. The exact way depends on the specific processor and mapping error. If you have implemented ''printk'' it may be a good idea to add some code to ''bsp_pretasking_hook'' to show you the base and size:
    48 
    49 {{{
    50           printk ("Heap : %5d KB @ 0x%08x\n   ", heap_size >> 10, heap_start);
    51 }}}
    52 
    53  * The initialization process encountered an error. The set of these is documented in the '''Classic API C User's Guide'''.  For RTEMS 4.6.1, this was documented in the [http://www.rtems.com/onlinedocs/releases/rtemsdocs-4.6.1/share/rtems/html/c_user/c_user00034.html Initialization Manager Failure] section.
    54 
    55  * Interrupts are pending and no interrupt handler is present, or a bug exists in the interrupt handler, or vector table layout. RTEMS will enable interrupts when it switches to the initialization task ''rtems_initialize_executive_late'' creates. This problem can be found by getting to the context switch call, ''_CPU_Context_Switch'', then the crash or lockup. The fix is to make sure the BSP has masked all sources of interrupts in the hardware around the processor. This allows RTEMS and the application an ordered and controlled initialization of driver and therefore interrupts.
    56 
    57 The initialization task is a real task in RTEMS. The ''rtems_initialize_executive_late'' creates it and switches context to it. This means your BSP environment is another context that RTEMS will switch back to when RTEMS is shut down. This allows your BSP to take control again, then perform any specific functions it needs. A typical operational thing to do is to reboot as embedded targets should not stop.
    58 
    59 = GDB Cannot Find My Source Files =
    60 
    61 
    62 If you find the source code paths in your executable as seen by GDB are missing, you may find using an absolute path to invoke the RTEMS configure script may help. When RTEMS libraries get built, nested ''Makefiles'' are executed that '''walk''' through the build directory structure. Therefore, each file is compiled from a certain point in the build directory structure that lies in parallel to the source directory structure.
    63 
    64 As a consequence of this, you get a varying number of "dots", depending on how deep the corresponding directory is inside the build tree. There is no common location, from which the source file pointers in the debug info is correct for all object files.
    65 
    66 If you call the initial <tt>configure</tt> in an absolute way such as :
    67 
    68  
    69    /usr/local/src/rtems/tools/rtems-4.6.0/configure
    70 
    71 
    72 rather than a relative way :
    73 
    74  
    75    ../rtems-4.6.0/configure
    76 
    77 
    78 GDB should find the source.
    7928
    8029= Starting With Hello World =
     
    11059
    11160RTEMS has very tight default configuration limits.  Not being able to open a file or create a socket is a common error which indicates that you need to configure enough open file descriptors.  By default, the constant CONFIGURE_LIBIO_MAXIMUM_DESCRIPTORS is set to 3 for stdin, stdout, and stderr.  You will need to set it to the appropriate value for your application.
    112 =  Optional Debugging Tools Provided by RTEMS  =
    11361
    114 
    115 There are a number of optional debugging tools available with RTEMS that are not too well documented (yet!).  These tools (and other goodies) can be found under cpukit/libmisc, and are well worth investigating.
    116 
    117 Note: Most of what follows has been gleaned from the associated README files; I haven't added much original content, partly due to sloth, but more justifiably because I haven't yet used these tools extensively enough to be able to do any better!  My primary purpose, at this point, in including these is so others, especially "nuBees" are aware of them.
    118 
    119 
    120 =  = FUTURE ====
    121 
    122 #Determine how/if gcc will generate stack probe calls and support that.