<!-- Start of markdown source --> Overview --- The Code Composer Studio memory map tells the debugger which areas of the target's memory it can and cannot access. By default, the memory map is disabled when CCS is first started. In this state, the debugger assumes all memory ranges are accessible and does not automatically prevent itself from accessing memory (reads and writes). When memory mapping is enabled, the debugger checks each memory access against the memory map, and prevents accesses to undefined or protected areas. Why Use Memory Mapping --- While it may seem preferable to have memory mapping disabled, there are a couple reasons that make the use of a memory map desirable. Firstly, memory mapping can improve debugger stability. The memory map is the only truly reliable means that the user has to indicate which memory locations can be touched by the debugger and which are to be avoided. In many cases, touching locations where no memory is implemented does not cause a problem. However, it can happen that reading a location in memory which does not exist will hang the memory bus (this is usually a design issue). In such cases, memory mapping can keep the user functioning, where a reset would otherwise be needed. Secondly, the memory map serves as a double check for the linker command file, and helps find code or data that might be linked to non-existent memory. A mismatch between the memory map and the linker command file will cause a Data Verification Error. To learn more about Data Verification Errors see the [dedicated page](https://software-dl.ti.com/ccs/esd/documents/troubleshooting-data_verification_errors.html) (especially the section on the debugger memory map). For more details on linker command files see [this document](https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_Linker-Command-File-Primer.html). The Memory Map View --- When connected to a target, you can view the memory map in CCS. To open the Memory Map view click on **Tools &rarr; Memory Map** (the Tools menu is available in the **CCS Debug** perspective).  The view shows the sections of memory in the memory map and their attributes (being readable, writable, etc.). Memory Map Setup --- The memory map is usually set up in a device initialization GEL file. These are often specified in the target configuration. The GEL functions for modifying the memory map are as follows (you can find more details in section 4 of [this document](https://www.ti.com/lit/an/spraa74a/spraa74a.pdf)): * `GEL_MapAdd()` and `GEL_MapAddStr()` add a section of memory to the memory map. * `GEL_MapDelete()` removes a portion of the memory map. * `GEL_MapOn()` and `GEL_MapOff()` turn the memory mapping feature on and off respectively. * `GEL_MapReset()` clears all of the settings in the memory map configuration. Below is a snippet from the initialization GEL file for the MSP432E401Y. ```C memorymap_init() { GEL_MapAddStr(0x00000000, 0, 0x00100000, "R", 0); /* Flash */ GEL_MapAddStr(0x01000000, 0, 0x00008c00, "R", 0); /* ROM */ GEL_MapAddStr(0x20000000, 0, 0x00040000, "R|W", 0); /* SRAM */ GEL_MapAddStr(0x40000000, 0, 0x00001000, "R|W", 0); /* WATCHDOG0 */ GEL_MapAddStr(0x40001000, 0, 0x00001000, "R|W", 0); /* WATCHDOG1 */ GEL_MapAddStr(0x40008000, 0, 0x00001000, "R|W", 0); /* SSI0 */ GEL_MapAddStr(0x40009000, 0, 0x00001000, "R|W", 0); /* SSI1 */ GEL_MapAddStr(0x4000A000, 0, 0x00001000, "R|W", 0); /* SSI2 */ GEL_MapAddStr(0x4000B000, 0, 0x00001000, "R|W", 0); /* SSI3 */ GEL_MapAddStr(0x4000C000, 0, 0x00001000, "R|W", 0); /* UART0 */ GEL_MapAddStr(0x4000D000, 0, 0x00001000, "R|W", 0); /* UART1 */ ... } ``` Additional information on GEL can be found in the [CCS User's Guide](https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-gel.html). <!-- End of markdown source --> <div id="footer"></div>