Skip to content
Snippets Groups Projects
Select Git revision
  • dw-cmsisdap-path
  • max32xxx default protected
2 results
Search by author
  • Any Author
  • 9R 9R
  • Administrator root
  • Andreas Schildbach pink
  • Daniel Hoffend griffon
  • Definitely Not A Robot Doloo1ai
  • Dirk Jäckel Dirk Jäckel biafra
  • G G
  • Hauke Mehrtens hauke
  • Jan Morawek RFguy
  • Julian hdsjulian
  • Lila Fisch lilafisch
  • Martin Ling martinling
  • Mateusz Zalega msgctl
  • Michael Huebler mh
  • Ole Dreessen ole
  • Phileas Phileas pl
  • Philip Brechler Philip Brechler plaetzchen
  • Renze renze
  • Sabine Wolf Bine
  • Sec 42 sec
20 authors
  1. Sep 30, 2009
  3. Sep 29, 2009
  5. Sep 28, 2009
  7. Sep 27, 2009
  9. Sep 26, 2009
  11. Sep 25, 2009
  13. Sep 24, 2009
  15. Sep 23, 2009
    • dbrownell's avatar
      Start handling the (second) SRST stage of reset better: · 23e22b6e
      dbrownell authored 
      make sure that when there are two or more targets, their
various pre/post event reports are correctly ordered.

Previously, only the first target always saw its "pre"
method before SRST was asserted or deasserted.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2753 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      23e22b6e
    • dbrownell's avatar
      When setting up an ETM, cache its ETM_CONFIG register. Then · 22045fa6
      dbrownell authored 
      only expose the registers which are actually present.  They
could be missing for two basic reasons:

 - This version might not support them at all; e.g. ETMv1.1
   doesn't have some control/status registers.  (My sample of
   ARM9 boards shows all with ETMv1.3 support, FWIW.)

 - The configuration on this chip may not populate as many
   registers as possible; e.g. only two data value comparators
   instead of eight.

Includes a bugfix in the "etm info" command:  only one of the
two registers is missing on older silicon, so show the first
one before bailing.

Update ETM usage docs to explain that those registers need to be
written to configure what is traced, and that some ETM configs
are not yet handled.  Also, give some examples of the kinds of
constrained trace which could be arranged.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2752 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      22045fa6
    • dbrownell's avatar
      Start cleaning up ETM register handling. On one ARM926 ETM+ETB · d9ce8a2f
      dbrownell authored 
      system, removes 20 non-existent registers ... but still includes
over 45 (!) ETM registers which don't even exist there ...

 - Integrate the various tables to get one struct per register
 - Get rid of needless per-register dynamic allocation
 - Double check list of registers:
    * Remove sixteen (!) non-registers for data comparators
    * Remove four registers that imply newer ETM than we support
    * Change some names to match current architecture specs
 - Handle more register info
    * some are write-only
    * some are read-only
    * record which versions have them, just in case
 - Reorganize the registers to facilitate removing the extras
    * group e.g. comparator/counter #N registers together
    * add and use lookup-by-ID


git-svn-id: svn://svn.berlios.de/openocd/trunk@2751 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      d9ce8a2f
    • dbrownell's avatar
      Initial ETM cleanups. Most of these are cosmetic: · a6d858eb
      dbrownell authored 
       - Add a header comment
 - Line up the ETM context struct, pack it a bit
 - Remove unused context_id (this doesn't support ETMv2 yet)
 - Make most functions static
 - Remove unused string table and other needless lines of code
 - Correct "tracemode" helptext

Also provide and use an etm_reg_lookup() to find entries in the ETM
register cache.  This will help cope with corrected contents of that
cache, which doesn't include entires for non-existent registers.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2750 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      a6d858eb
    • oharboe's avatar
      Nico Coesel <ncoesel@dealogic.nl> fix warnings. . I'm wondering why these · 7393fcfc
      oharboe authored 
      didn't turn up earlier. Is everyone still using gcc 3.x? Or is the x86
version of gcc 4.x much more relaxed?

git-svn-id: svn://svn.berlios.de/openocd/trunk@2749 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      7393fcfc
  17. Sep 22, 2009
  19. Sep 21, 2009