Difference between revisions of "Debugging self-modifying code in flash"

From SEGGER Wiki
Jump to: navigation, search
Line 3: Line 3:
 
* The application contains self-modifying code
 
* The application contains self-modifying code
 
* There are some constant arrays etc. downloaded as part of the application but these are modified during the execution (e.g. non-volatile configuration data etc.)
 
* There are some constant arrays etc. downloaded as part of the application but these are modified during the execution (e.g. non-volatile configuration data etc.)
When debugging such cases, memory windows etc. in the IDE may show the original (now incorrect) value. In order to debug such cases, J-Link needs to be aware of that certain ranges of the flash memory are considered to be "volatile" during the debug session.
+
When debugging such cases, memory windows etc. in the IDE may show the original (now incorrect) value. In order to debug such cases, J-Link needs to be aware of that certain ranges of the flash memory are considered to be "volatile" during the debug session. This can be achieved by the
  +
bla
  +
command string. For more information about this command string and how to use command strings in different environments, please refer to ''UM08001, chapter "Command strings"''.

Revision as of 15:10, 17 February 2017

By default, when downloading an application to flash via J-Link, it is assumed that this application does not change during the debug session. This allows J-Link to do some optimization like caching certain target contents and so speed up debugging (depending on the IDE integration and the behavior of the IDE, reaction time can be 2-3 times faster with caching certain contents). However, there are cases where the application, downloaded at debug session start, may change during debugging it. These case are for example:

  • The application contains self-modifying code
  • There are some constant arrays etc. downloaded as part of the application but these are modified during the execution (e.g. non-volatile configuration data etc.)

When debugging such cases, memory windows etc. in the IDE may show the original (now incorrect) value. In order to debug such cases, J-Link needs to be aware of that certain ranges of the flash memory are considered to be "volatile" during the debug session. This can be achieved by the

bla

command string. For more information about this command string and how to use command strings in different environments, please refer to UM08001, chapter "Command strings".