Getting unknown addresses in instruction trace

From SEGGER Wiki
Revision as of 17:03, 22 September 2017 by Nino (talk | contribs) (Created page with "Under certain circumstances it is possible that debug software outputs instruction trace packets as "unknown address". This article will describe why this could be happening a...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Under certain circumstances it is possible that debug software outputs instruction trace packets as "unknown address". This article will describe why this could be happening and how to fix the issue.

Introduction

The reason for getting unknown addresses is that to be able to reconstruct instruction trace the J-Link software needs to have cached the contents of the executed memory area. Per default only readonly memory, such as Flash, is cached on download. Already present flash content, e.g. a bootloader, is not read back, nor is RAM cached automatically.

Main causes

The main causes for this are:

  • The application is running from RAM which is not cached by default
  • The target device already has something (e.g. a bootloader) programmed to Flash, so when a new additional application gets downloaded only the newly added memory are will be cached.
  • The user attaches to a running program. In this case no memory at all is cached as no application has been downloaded for J-Link to know which memory areas are affected.

How to get correct trace output

To enable trace cache for one of the aforementioned scenarios the exec command ReadIntoTraceCache needs to be used. The syntax is as follows: ReadIntoTraceCache <Addr> <NumBytes>

How to use exec commands is described in the J-Link User Manual (UM08001).

Note: This command causes an immediate read from the target, so it should only be called at a point where memory contents at the given area are known to be valid.