Difference between revisions of "Debugging self-modifying code in flash"
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. This can be achieved by the |
+ | 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 '''EcludeFlashCacheRange''' J-Link 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"''. |
ExcludeFlashCacheRange <SAddr>-<EAddr> |
ExcludeFlashCacheRange <SAddr>-<EAddr> |
||
Example: |
Example: |
||
Line 10: | Line 10: | ||
// |
// |
||
ExcludeFlashCacheRange 0x08000000-0x0800FFFF |
ExcludeFlashCacheRange 0x08000000-0x0800FFFF |
||
− | 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:59, 26 January 2018
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 EcludeFlashCacheRange J-Link 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".
ExcludeFlashCacheRange <SAddr>-<EAddr> Example: // // Mark the first 64 KB of the flash as volatile // ExcludeFlashCacheRange 0x08000000-0x0800FFFF