D.Module.HowTo's

As a new D.Module customer you have purchased a DS or DK package, including the D.Module, base board, support software, documentation, power supply, cables - and, in case of the DK package, code generation tools and in-circuit emulator.

Installing the D.Module:

Mount the D.Module on the base board, make sure the orientation is correct:

Connect the base board RS232 with a free COM port on your PC. Use the 9-pin cable supplied with the DS (or DK) package. Finally connect the power supply. The green LED on the base board will light.

Configure your terminal program:

Start your favorite terminal program on the PC. You may use the Hyperterminal program supplied with the Microsoft® Windows® operating system. Select the COM port to which the D.Module is connected and set the port parameters to 9600 baud, 8 databits, 1 stopbit, no parity, and software (Xon/Xoff) flow control. No special terminal emulation mode or ASCII configuration is required, use the defaults.

First contact:

Now its time to press the reset button on the D.Module base board (or disconnect and reconnect the power supply). The D.Module is factory-programmed with a test program which will write its output to the terminal.
If nothing is displayed on your terminal, please check the cabling and terminal settings. To make sure the D.Module is sending data, connect the Test Pin on the base board to pin A3 of the D.Module with a piece of wire. A short flash of the yellow LED on the base board after pressing the reset button indicates the module is transmitting data on the RS232 port. If your D.Module has been in use before, maybe the Module Configuration File or the BIOS/Setup is corrupted. Please refer to HowTo recover a corrupted configuration file and HowTo recover the D.Module.BIOS and Setup-Utility

Getting familiar with the Setup Utility:

All D.Modules feature a built-in Setup Utility for program uploads, User-CPLD configuration, etc. This utility is invoked by keeping the Setup button on the base board pressed during a Reset: Hold the Setup button pressed, then press and release the Reset button, finally release the Setup button. Your terminal will now display information about the module hardware and software and a help screen showing the available commands. The commands are described in detail in the module User's Guide.

Code Generation Tools and In-Circuit Emulator:

First install the code generation tools on your PC, then the in-circuit emulator drivers following the manufacturers installation guide. Make sure all virus and malware protection software is disabled - this often has caused installation problems. Also make sure you have the required permissions to install software and device drivers.
Now connect the emulator to the D.Module, connect the power supply, and start the emulator configuration program and test utility. Configure the emulator driver by selecting your emulator hardware, in some cases the emulator base address or ID must also be specified. If you are asked for a board.dat file describing the JTAG chain: the default or auto-generated is suitable for the D.Modules. Finally specify the appropriate CPU for this emulator board, i.e. the DSP type used on your D.Module. Run the JTAG chain tests in the emulator test program. It should reset the emulator, initialize the JTAG chain and detect a device. If this fails, please refer to the emulator User's Guide to make sure the configuration is correct. Typical errors are: wrong base address, power supply not connected, or missing administration rights to install hardware device drivers on your PC.
If you are using the C3x/4x Code Composer, you need to install the DSP peripheral support library. Open a command window in CC_DIR\c3x4x\cgtools\lib and execute mk30 --h prts30.src. This will build the prts30.lib and extract the peripheral header files. Move the header files to CC_DIR\c3x4x\cgtools\include.

Install the D.Module support software:

Create a directory of your choice where the support software should be installed and copy all files from the CD. Modules with a Texas Instruments DSP have a .gel file in the \dmodule\ subdirectory. Specify this GEL file in the Code Composer Studio setup as the startup GEL file. All D.Modules use a bios.h header file defining constants, types, and prototypes for the built-in D.Module.BIOS functions. This file is also found in the \dmodule\ directory and must be included in all projects. You may want to copy this file to the code generation tools \include\ directory to avoid the need to copy it into each new project. If you use different D.Modules, rename the bios.h file to avoid conflicts, e.g. bios6713.h
For modules with a Texas Instruments C6000 DSP the dhex6x.exe utility is provided in the D.Module support software, directory \dmodule\. This program is used to generate .hex files for execution from the D.Module Flash Memory. Copy this file and the associated dhex6x.hlp to the \cc\bin\ directory of your Code Composer installation to make is accessible. If you like, create a shortcut to this program and put it into the Code Composer group in your start menu.

To make a program executable from the D.Module Flash Memory please follow these steps:

ADI Visual DSP:

Open the project options dialog, project tab, and select DSP Loader File as the Target Type. Then open the Load tab and enter 0x10000 as the start address. All other default settings (boot type = PROM, boot format = HEX, use default kernel) are appropriate.
Following program compilation and linking, a .ldr file will be generated.

TI Code Composer Studio:

Open the Project Build Options, Linker tab, and set the Output Module to Absolute Executable. Make sure the Autoinit Model is set to Run-Time Autoinitialization. Following compilation and linking execute the dhex6x.exe utility program and load your .out output file. The default options of dhex6x need not to be changed. Dhex6x will generate a .hex file.
If you are using DSP/BIOS in your project dhex6x may generate a warning (output section below 0x200 found, file may not be bootable). This warning can be ignored because DSP/BIOS replaces the default interrupt vector table with its own.

TI Code Composer for C3xC4x:

The default project settings are suitable (Linker: Absolute Executable, ROM Autoinitialization Model). Following compiling and linking you have to run the hex30.exe utility in the Code Composer \c3x4x\cgtools\bin\ directory. Hex30 is best used with a command file. Please take one of the hex30 command files from the D.Module support software. These files are named xyz2hex.cmd (with xyz = program name). Open with a text editor and replace the .out file name and the .hex file name with your program names and save the .cmd file in your project directory. Open a command window and execute hex30 xyz2hex.cmd - the .hex file will be generated.

Upload to the D.Module:

Connect the D.Module to your terminal program and enter Setup mode as described in HowTo install and test the D.Module. Enter a 'u' in the terminal. The D.Module will prompt for the file type to upload (not on D.Module.21065 and D.Module.C31eco). Enter 'i' for Intel-Hex. The D.Module will prompt for the .hex hile. Upload your hex (or .ldr) file in ASCII mode. In Hyperterminal select transfer, text file. You will notice a short delay after the first two lines are transmitted. This delay is caused by the Flash Memory programming algorithms: the destination address has now been read from the hex-file and the destination sector is erased. When the file has been transmitted completely the module will respond with 'upload successful'. Now reset the module: your new program will be executed.
Loader files generated by VDSP lack a final CR/LF. If you upload such a .ldr file, the Setup utility cannot determine the end of the file. Either open the .ldr file with a text editor and add a final CR/LF before upload, or press Enter in your terminal window if the last line of the .ldr file is displayed (:00000001FF).

If upload fails, the most likely reason is a wrong configuration of UART flow control. Flow control is required to halt the transmission while a Flash sector is being erased (this operation may take up to one second). By default D.Modules use Xon/Xoff software flow control. Make sure this is configured in your terminal too. If Xon and Xoff characters are configurable, make sure Xon is set to 0x11 and Xoff is 0x13.
Flow control parameters may have been changed in the D.Module Configuration file (not 21065 and C31eco). Enter 'd' for download and 'c' for config in Setup utility, then enter 'c' to start the download. The Module Configuration file will be displayed in the terminal. Check the handshake and Xon and Xoff code settings in the [UART] section and make sure your terminal is configured accordingly. The handshake setting in the Config File must be set to Xon/Xoff or RTS/CTS (only the first character is significant). If the configuration file is corrupted, please refer to Howto recover a corrupted Module Configuration File

(not applicable to D.Module.21065 and D.Module.C31eco)
The D.Module Configuration File stores UART communication parameters and other hardware-related items. It can also be used to store user-defined data. If the Configuration File has been corrupted, it may not be possible to access the D.Module Setup Utility any more. A typical problem is a typo in the [UART] section, e.g. baudrate=11520 instead of 115200. To check or replace the configuration file in such a case, connect the D.Module IN1 input (Pin A12) to GND (Pin A13). Configure your terminal to the default parameters 9600,8,N,1,Xon/Xoff. Now start the Setup Utility (hold Setup button down during Reset). If IN1 is found low on reset, the Configuration File will not be processed and the default parameters will be used. You can now download the Configuration File and correct errors or upload a known good Config file.

In very rare cases the D.Module.BIOS and/or the Setup Utility may have been corrupted or erased from the Flash Memory. Although the BIOS functions do not allow to erase or program the Flash Memory sectors containing BIOS and Setup, custom Flash programming routines or a badly malfunctioning program (stack overflow or similar) might be able to corrupt these sectors.
To recover the D.Module.BIOS and Setup an emulator is required and a terminal connection at 9600 baud, 8 databits, 1 stopbit, no parity, Xon/Xoff software flow control. Load the recovery.out program from the support software, directory \dmodule\ using the debugger/emulator and start it. The program will prompt to upload the bios.hex file. Send this file (also located in the \dmodule\directory) using ASCII transfer (Hyperterminal: transfer text file). After the transfer is done disconnect the emulator and you should be able to invoke the Setup Utility again.
Depending on the module more than one bios.hex file may exist in the \dmodule\ directory. Make sure to select the correct file! The file names are self-explanatory. If in doubt which file to use, please contact support@dsignt.de and send us the type and serial number of your board.
Please note that the Module Configuration File remains unaffected by the BIOS/Setup recovery. The module will operate with the communication settings defined in the [UART] section. If you still have problems to communicate with the module, please read HowTo recover a corrupted Module Configuration File.

These parameters are stored in the D.Module Configuration File. The default files are located in the support software, directory \dmodule\. If you want to change the settings, copy the config.txt file for your module and assign a new name. Open the file with a text editor and make the desired changes. Then bring the module into Setup mode as described in Howto install and test the D.Module. Enter 'u' to upload a file and select 'c' for config file when prompted for the file type. The module will respond with "ready to receive". Now upload your modified Config File using ASCII transfer (Hyperterminal: transfer text file). The changes will take effect after resetting the module.
21065 and C31eco modules do not use a config file. It is not possible to permanently change the baud rate. If you want to speed up program uploads, enter the 'b' command and enter the desired baud rate. Change baud rate in your terminal program and press 'c' when done. You may use a terminal program with scripting support to automate this, like the highly recommended TeraTerm program.

D.Module.C6000 Code Composer Studio:

Create a new project (project, new) and select the target DSP family. Open the project, build options dialog, compiler tab, basic, specify the correct target DSP and select the desired optimization settings. In the advanced settings select the appropriate memory model:
If your global and static data exceeds 32K bytes, select the far model. If your program code will exceed 1M byte, or functions are spaced more than 1M byte apart, you must also use the far model. We recommend to use the far model by default for any new project - you may tweak these options later if everything works as expected.
In the Linker tab, basic, set the output module to absolute executable and specify the required heap and stack size. The defaults are heap=0x400 and stack=0x400.
We recommend to rebuild one of the sample programs first, e.g. the timer program. Copy timer.c and timer.cmd to your new project directory. If bios.h isn't placed in the CCS include directory, this file must be copied to your project directory too.
Add files timer.c and timer.cmd to your project. Open timer.cmd and remove the entries starting with timer.obj and ending with -l rts6700.lib. This is also commented in the timer.cmd file. These entries are used if you work with the command line tools to build your project. If using CCS, these entries are specified in the project options. Finally you must add the C runtime library rts****.lib to your project. It is located in CCS_DIR\DSP_Family\cgtools\lib\. The D.Modules use little endian format by default, for the C6713 for example use the rts6700.lib.
Now you are ready to build the project.
If you want to debug your program using the simulator instead of the in-circuit emulator, please refer to HowTo use a D.Module with the Simulator Debugger.

D.Module.VC33/C31eco Code Composer:

As a first step we encourage you to rebuild one of the sample programs from the support software, e.g. the timer program. Copy files timer.c and timer.cmd into your project directory. If bios.h has not been placed in the Code Composer include directory copy this file into the project directory too. Then create a new project (project, new) in this directory, and add timer.c and timer.cmd to the project. Also add the C runtime support library to your project. This is file rts30*.lib, located in CC_DIR\c3x4x\cgtols\lib\. Depending on the memory and argument passing model select the appropriate library. We recommend to use the small memory model and register argument passing. The correct library is rts30r.lib.
Open the project options dialog, compiler tab, and specify the suitable target processor. Select the desired optimization level. In the memory model category, check "pass arguments in registers". If your global and static data will exceed 64K words, check "enable big memory model" and replace the C runtime library in your project with rts30gr.lib. In the Assembler tab, also select the correct target device family and check "register argument passing compatibility" and - if required - "big memory model compatibility". In the Linker tab, specify stack size = 0x3FE and heap size (default is 0x1000). If a larger stack is required, you must assign the .stack section to a memory area other then RAM0 in the linker command file (timer.cmd)
Then open the timer.cmd linker command file and delete the first entries from timer.obj to -o timer.out. These entries are only required if you use the command line tools. When using Code Composer, these settings are made in the project options dialog.
Now you are ready to build the project.
If you want to debug your program using the simulator instead of the in-circuit emulator, please refer to HowTo use a D.Module with the Simulator Debugger.

D.Module.21065 Visual DSP:

As a first step please try to rebuild one of the sample program from the support software, e.g. the timer program. Create a new directory for the project and copy files timer.c and d21065.ldf into this directory. If bios.h was not copied to the VDSP++ include directory, you must copy it to your project directory too.
Create a new project. The Project dialog will open. In the Project tab select the correct target processor: ADSP-21065L. In the compile tab select the desired optimization settings. When closing the dialog, do not add support for the VDK kernel to the project. Finally add files timer.c and d21065.ldf to the project.
Now you are ready to build the project.
If you want to debug your program using the simulator instead of the in-circuit emulator, please refer to HowTo use a D.Module with the Simulator Debugger.

The D.Module.BIOS functions are located in the module hardware (the Flash Memory) and copied to RAM at boot time. These functions are not available to the simulator. Calls to D.Module.BIOS functions from your C program will cause the simulator to crash. We recommend to replace these D.Module.BIOS calls and direct access to any off-chip peripherals with stdout calls for use with the simulator using #ifdefs:

  #define USE_SIM 1

  #ifdef USE_SIM
  #include <stdio.h>
  #endif

  #ifdef USE_SIM
    puts ("init_module()");
  #else
    init_module();
  #endif  

  #ifdef USE_SIM
    putc (c, stdout);
    putc (*s, stdout);
  #else 
    send_char (c);
    UART->UART_THR = *s;
  #endif

DSP internal program and data memory is the fastest available memory and guarantees best performance, but resources are limited. If you are running short of fast internal memory you may want to move non-timecritical code (e.g. initialization functions) and less frequently accessed data to slower memory, but keep the time-critical parts in fast internal memory. By default code is mapped to the .text or seg_pmco segment. To place code and/or data in a user-defined section, use the #pragma CODE_SECTION(); and #pragma DATA_SECTION() instruction for TI DSPs, and the segment() qualifier for Analog Devices DSPs.

Texas Instruments

  #pragma CODE_SECTION (slow_func, ".slowtext"); 
  int slow_func (...)
  {
    /* non-time-critical code, will be mapped to section .slowtext */
  }

  int other_func (...)
  {
     /* this function code will be mapped to the default .text section */
  }

  #pragma DATA_SECTION (initialization_data, ".slowdata");
  int initialization_data[16]; /* will be mapped to .slowdata section */
  int other_data;              /* will be mapped to .bss (if global)
                                  or exist on stack (if automatic)    */
                                  

Note: in C++ the function or variable name is not specified in the #pragma, e.g.
#pragma DATA_SECTION (".slowdata");

The new sections .slowtext and .slowdata must be defined in the Linker Command File (see notes for DSP/BIOS). A typical linker command file looks like this:

MEMORY
{
  /* internal memory */
  ...
  
  /* external memory */
  SDRAM: org = 0xB0000000, len = 0x01000000
}

SECTIONS
{
  .text     > IRAM    /* time-critical code in fast internal RAM */
  .slowtext > SDRAM   /* non-time-critical code */
  .stack    > IRAM    
  .bss      > IRAM    /* default fast global and static data */
  .slowdata > SDRAM   /* non-time-critical global and static data */
  .far      > IRAM
  .const    > IRAM
  .switch   > IRAM
  .cinit    > SDRAM
  .sysmem   > SDRAM
  .cio      > SDRAM
}

C6000 Cache Notes

For best performance make the external memories L1-cacheable. Depending on your program, L2 cache may also be beneficial, but this will further reduce internal memory. In some cases however, a large L2 cache with all code and data in external memories might give the best results.

Notes for C6000 DSP/BIOS Users

If using DSP/BIOS, never change the auto-generated linker command file to add additional sections! Instead remove the auto-generated .cmd file from your project (the default name is MyProjectNamecfg.cmd, and add your own linker command file. This must load the auto-generated command file, and define the required additional sections. In our example:

-l MyProjectNamecfg.cmd

SECTIONS
{
  .slowtext > SDRAM   /* non-time-critical code */
  .slowdata > SDRAM   /* non-time-critical global and static data */
}

The DSP/BIOS Configuration Memory Manager allows to assign the standard sections to specific memory areas. The .cinit data section for example is only used on program startup. This is a good candidate to be moved to SDRAM. Be careful when moving other standard sections: DSP/BIOS requires some sections to reside in identical memory areas. Always verify correct program execution.

Analog Devices

    
  segment ("slowcode") int slow_func (...)
  {
    // non-timecritical code, will be mapped to section slowcode
  }

  int other_func (...)
  {
    // this code will be mapped to the default seg_pmco section 
  }
   
  segment ("slowdata") int init_data[16];  // mapped to slowdata section   
  int other_data;                          // mapped to default data section

The new sections slowcode and slowdata must be defined in the LinkerDescription File:

  MEMORY
  {
    // internal memory
    ...
  
    // external memory
    ext_code { TYPE(PM RAM)  START(0x00020200) END(0x00023FFF) WIDTH(32) }
    ext_data { TYPE(DM RAM)  START(0x00028000) END(0x0002BFFF) WIDTH(32) }
    seg_heap { TYPE(DM RAM)  START(0x0002C000) END(0x0002FFFF) WIDTH(32) }
  }

  SECTIONS
  {
    external_code
    {
      INPUT_SECTIONS( $OBJECTS(slowcode) )
    } > ext_code

    external_data
    {
      INPUT_SECTIONS( $OBJECTS(slowdata) )
    } > ext_data
    
    internal_code
    {
      INPUT_SECTIONS( $OBJECTS(seg_pmco) $LIBRARIES(seg_pmco))
    } > seg_pmco

    ...
  }

In VDSP++, external code and data sections declarations must preceed the default sections