CrossStudio's New Project Wizard simplifies the creation of projects for the Cogent CSB637 by creating a project with the appropriate project settings, memory map files and startup files. See Creating a New Project for more information on creating projects.

##### To create a new Cogent CSB637 project

- Select the File | New | New Project menu item.
- Select Cogent | CSB637 Projects from the Project Type list.
- Select the required project template type from the Templates list.
- Set the required project name and location directory.
- Click OK.

CrossStudio for ARM supports the Cogent CSB637 running applications from both RAM and FLASH.

Warning: Downloading to FLASH will erase the and re-program the FLASH memory thus removing the boot loader firmware shipped with the board.

##### To build and debug an application running from RAM

- Select the project to work on by using the Project | Set Active Project menu option.
- Select the RAM configuration you require by using the Build | Set Active Build Configuration menu option.
- Build the project by using the Build | Build Project menu option.
- Connect to the appropriate target in the target window.
- Download and start debugging the current project by using Debug | Start Debugging.

##### To build and debug an application running from FLASH

- Select the project to work on by using the Project | Set Active Project menu option.
- Select the FLASH configuration you require by using the Build | Set Active Build Configuration menu option.
- Build the project by using the Build | Build Project menu option.
- Connect to the appropriate target in the target window.
- Download and start debugging the current project by using Debug | Start Debugging.

The following sections describe the Cogent CSB637 support in more detail. See ARM Target Support for more information.

### Memory Map Files

The default memory map file $(StudioDir)/targets/Cogent_CSB637/CSB637_MemoryMap.xml has been provided. This file is used to describe the memory layout of the target and is used for linking and debugging. The placement of program sections within the memory map for both RAM and FLASH configurations is described by the non-target-specific default memory maps $(StudioDir)/targets/flash_placement.xml and $(StudioDir)/targets/sram_placement.xml.

The memory segment layout for both configurations is the same and is described in the following table:

Type | Description | Start Address | End Address
RAM | Internal SRAM | 0x00200000 | 0x00203FFF
FLASH | External FLASH | 0x10000000 | 0x10FFFFFF
RAM | External SDRAM | 0x20000000 | 0x27FFFFFF

The internal SRAM is also aliased at 0x00000000 for both FLASH and RAM configurations in order to support the ARM exception vectors.

The default configuration enables the MMU in order enable the instruction and data caches. The MMU is configured to use a simple flat memory translation where virtual addresses equal physical addresses. Some of the external SDRAM has been reserved for MMU support, the following table describes how the external SDRAM has been divided:

Description | Start Address | End Address
System RAM | 0x20000000 | 0x20005FFF
Non-cacheable RAM | 0x20006000 | 0x20007FFF
Cacheable RAM | 0x20008000 | 0x27FFFFFF

The Cacheable RAM and Non-cacheable RAM address ranges are available to applications. The System RAM address range is reserved for supporting the MMU and is structured as follows:

Description | Start Address | End Address
MMU Translation Tables | 0x20000000 | 0x20004FFF
MMU Debugger Code | 0x20005000 | 0x20005FFF

In addition to the cacheable region of the external SDRAM the internal SRAM, the external FLASH and the first 1MB of memory are configured as cacheable memory.

### Target Startup Code

The default startup code is in $(StudioDir)/targets/Cogent_CSB637/CSB637_Startup.s. It contains the exception vectors, the default exception handlers, clock configuration and MMU initialisation. The FLASH version of the code (specified by defining __FLASH_BUILD) is also responsible for configuring memory to match the above memory map and copying the exception vectors into RAM.

### Troubleshooting

It is not possible for the debugger to reset this target prior to download or debugging therefore if you run a program that crashes you will probably find the debugger is unable to control the target until it has been power cycled. This can be particularly problematic if the program that crashes is running from FLASH, if the program crashes shortly after power up it can appear that the target is not working. If this happens carry out the following actions:

- Remove the board's BMS jumper.
- Power cycle the board.
- Download a know working program into the FLASH.
- Reattach the BMS jumper.
- Power cycle the board.

The lack of reset may also cause other problems as the peripherals will not be reset when you run a program thereby leaving the registers in the state programmed by the last running program. To work around this you can either make sure you program does not rely on peripherals being in their reset state or you can manually power cycle or reset the target and attach the debugger to a running system using Debug | Attach.