packages/hal/coldfire/arch/v2_0/doc/readme.txt

   1 SOME NOTES ON THE USAGE OF THE HAL FOR COLDFIRE
   2
   3 This HAL was obtained by rewriting the original port of eCos to ColdFire done
   4 by Wade Jensen. The following guidelines give you hints about using this
   5 software.
   6
   7 * Use at least GCC version 3.4.1. This version has an improved support for
   8   ColdFire processors. However, this compiler might not be able to build the
   9   "cxxsupp.cxx" test in the "infra" package.
  10
  11 * The version of the binutils I used is 2.15.90.0.1.1.
  12
  13 * The version of newlib I used is 1.13.0.
  14
  15 * The version of the BDM tools I used is 1.3.0.
  16
  17 * If you want to debug code by means of the serial connection to eCos, don't
  18 use a version of GDB with BDM support compiled into. There is some kind of
  19 interaction between BDM and serial targets that prevents the latter from
  20 functioning correctly. Do not even use a clean GDB 6.3 distribution to debug
  21 through the serial cable. The downloading of code to the target is broken in
  22 that version. Instead, use a version of GDB grabbed from CVS repository. I
  23 used a version downloaded after June 13, 2005, and the bug had been corrected.
  24
  25 * Currently (version 6.3), GDB doesn't support the ColdFire MAC unit. Thus, it
  26 is not possible to show the MAC registers, via the "info registers" command,
  27 when debugging an eCos application through a serial connection. The BDM addon
  28 to GDB doesn't suffer from a similar limitation. However, there is a little
  29 hack in order to show and modify the MAC registers even with a serial
  30 connection. When a breakpoint is hit, the GDB module of eCos stores the
  31 current register values in a structure of type HAL_SavedRegisters, pointed to
  32 by the _hal_registers variable. If you included the GDB stub in your
  33 application, it is then possible to display the MAC registers (and all of the
  34 others) by issuing at the GDB prompt the following command:
  35
  36 print *(struct HAL_SavedRegisters *)_hal_registers
  37
  38 In case you are using a GDB stub burned in ROM to debug an application in RAM,
  39 you first have to determine where the GDB stub stores the _hal_registers
  40 variable in its own private region of RAM: use the tool m68k-elf-objdump to
  41 find that. For example, if the address of the _hal_registers variable used by
  42 the GDB stub is 0x1e88, then you should use the following command to display
  43 the registers of the application being debugged:
  44
  45 print *(struct HAL_SavedRegisters *)*0x1e88
  46
  47 It is also possible to modify the value of the MAC registers, by updating the
  48 relative field of the HAL_SavedRegisters structure. Don't try to modify the
  49 other registers because the modifications will be discarded when the
  50 application is restarted: use the usual GDB commands instead. Finally, the
  51 correct value of the PC register is the one shown by the "info registers"
  52 command.
  53
  54 * I added at the architecture level only the features that I could directly
  55 test. When I developed the architecture HAL, I had a ColdFire MCF5272 at
  56 hands, which has a MAC unit. That's why in the architecture HAL there is
  57 currently only support for the MAC unit, and no support for the EMAC and
  58 floating point units. However, I tried to write the HAL in the most generic
  59 fashion I could imagine, in order to make it easy to add new architectural
  60 features and new processor variants.
  61
  62 * If you want to burn an eCos image into the flash ROM, you cannot rely on the
  63 ROM monitor provided with the board, but you have to use the BDM interface.
  64 If you work under Windows, you can use the free CFFlasher utility, available
  65 on the Freescale Semiconductor web site. The BDM tools also contain a
  66 text-mode utility to do that, but I have not tested it.
  67
  68
  69 Enrico Piria (epiria AT fastwebnet DOT it)
  70 November 16, 2005