D.Module.FAQs

Since newer notebook computers do no longer provide the legacy RS232 port, you must use a USB-RS232 converter to communicate with a D.Module in Setup Mode. Many of the cheap adapters however have implemented flow control erronously: After receiving an Xon, these adapters repeat the entire last block instead of proceeding with the current character. This causes Intel-Hex format errors during program uploads to the D.Module Flash Memory.

Fortunately there are several converter chips available which handle flow control correctly. A known good device for example is the Silicon Laboratories CP2103. You may use their CP2103EK evaluation board (EUR30..50).

Please check the following:

1. Some terminal programs hang and block communications if an erronous character has been received. Please restart your terminal program and try again before proceeding.
2. Make sure you are using the correct interface. D.Modules are available with RS232 (default) and RS422 (optional) line interfaces.
3. RS232 cabling: If you use the D.Module.Base Board, you must use a 1:1 cable as supplied with the base package, not a null modem cable! If you operate the module on a custom base board, make sure all RS232 connections are correct. Please note that some terminal programs do require a valid DSR and/or CD signal. This is achieved by connecting DSR and CD directly to DTR (9-pin D-Sub: connect pins 1,4, and 6). This connection already exists on the D.Module.Base Board, but may be missing if using a custom base board.
4. The terminal program configuration must match the settings in your Module Configuration File (not applicable for D.Module.C31eco, D.Module.C6x01 Rev1, and D.Module.21065). The default is 9600 baud, 8 data bits, no parity, 1 stop bit, Xon/Xoff Software Flow Control. If you use Hyperterminal: please load the terminal configuration file supplied with the D.Module support software, subdirectory terminal. Also verify the COM port (to which the module is connected) matches the settings in the terminal program configuration.
5. Erronous Module Configuration File: maybe there is a typo in your Module Configuration File, e.g. baud=11520 instead of baud=115200. The D.Modules provide a method to overwrite these settings and fall back to the default 9600,8,N,1,Xon/Xoff (see User´s Guide, Chapter UART): connect IN1 (D.Module pin A12) to GND (pin A13) and enter Setup Mode. If a communication can be established now, fix the Module Configuration File and upload it to the Module.
6. Check the RS232 transmitter with an oscilloscope. All D.Modules do send a series of characters after entering Setup mode. You should be able to see valid transmit data on pin A3 on your oscilloscope. If not:
7. Load file recovery.out from the D.Module support software, directory dmodule, in Code Composer / VisualDSP. Set your terminal program to 9600,8,N,1,Xon/Xoff. Start recovery.out. If communications work now, reinstall the D.Module.BIOS
8. The UART or RS232/RS422 interface may be damaged, please send back the module for repair.

Hyperterminal has been reported to cause problems with Xon/Xoff Flow Control on some Windows installations. Program uploads (Intel-Hex uploads) may take half an hour or more, although, at 9600 baud, a 100 Kbyte Intel-Hex File upload should complete in 107 seconds. Try to use RTS/CTS hardware flow control instead by changing the entry in the Module Configuration File to "handshake=RTS/CTS". You may also try TeraTerm.exe - a freeware terminal program we found very useful and reliable. Download it from the Author´s Website .

Please check:

1. Does your program execute correctly if loaded via Code Composer/VisualDSP? Please make sure that all variables are initialized properly. Some emulator/debugger zero-fill the variable space. This is not done if bootloading from Flash: clear all the program and data memory used by your application (except the D.Module.BIOS memory areas!), e.g. by filling it with a random number, and reload your program. If it executes as intended, please read further, otherwise check which variable(s) lack proper initialization.
2. Check the project options: in Code Composer you must select "absolute executable" and use "Runtime Initialization" to generate bootloadable programs. Always verify the correct DSP target device is specified, as this may have an impact on the bootloader code for C3x and Sharc DSPs.
   Additional information is found in our HowTo's
3. Check the Hex Conversion Tool settings: the default address of an application program is at offset 0x10000 in Flash Memory.
   Sharcs: make sure the correct bootloader file (xxx_PROM.dxe) is specified
4. Check the Module Configuration File: Does the "run=" entry in the [PROGRAM] section match the settings of the Hex Conversion Tool? If there is a "load="entry, e.g. to execute a power-on self test program prior to the application, make sure the program specified there is available in the Flash Memory and executes correctly, or delete the "load=" entry for a first test.

The D.Module.BIOS functions are bootloaded from Flash Memory at power-up and/or Reset and stay resident in the DSP memory. If a BIOS function is called, but it´s code is not available in memory, the program will crash or hang. Two possible reasons exist:

1. The BIOS functions have not been bootloaded on power-up. This may occur if the emulator was connected to the D.Module before it was powered-up. The emulator may halt the DSP and prevent it from bootloading.
   Either exit Code Composer / VisualDSP, disconnect the emulator pod from the D.Module, and reset the module (power-cycle or reset-button on the D.Module Base Board), or set the debugger to "run free" mode and reset the module. The BIOS will be bootloaded and is available to your program.
2. The BIOS functions have been corrupted by a program crash. A stack overflow, an out of range pointer operation, or a DMA transfer may have overwritten the BIOS code. Reload the BIOS as described in 1.) To make sure that no "faulty" executable program is bootloaded from Flash which may itself damage the BIOS functions in memory, it is recommended to put the module in Setup mode, rather than a simple reset.
3. In rare cases a program crash may have even deleted the BIOS from Flash memory, or has overwritten some of the Flash memory contents. Put the module in Setup mode. If Setup mode works properly, the BIOS functions in Flash are intact. If not, reinstall the BIOS using the recovery executable from the support software. See the User´s Guide or the HowTo's for details.

If you want to use the simulator to debug code written for a D.Module, the D.Module.BIOS functions cannot be used. Please see our HowTo's for simulator debugging.

To mount a D.Module board on your own custom base board use standard IC socket strip connectors:

• Tyco/AMP 210826, see AMP/Tyco
• W+P 187-321-10-50-10 from W+P
• Preci-DIP 310-91-132-41-001 from CAB
• press-fit type 930-61325 from EPT
• or similar products.

For daughter board designs the following connectors may be used:

• Tyco/AMP 210735, see AMP/Tyco
• press-fit type 930-66325 from EPT
• SIB-132-F623-xx from E-Tec
• or similar.

If none of the above products should be available at your location, the data sheets and part numbers of the above manufacturers may help to find similar or second source products.

The programming and development tools are available from the manufacturer's website free of charge, only registration is required.

For Modules using Lattice ispLSI2032(V)(E) CPLDs (D.Module.C31eco and D.Module.C6x01 Rev. 1 (before June 2002)), load the ispLever Starter software from Lattice Semiconductor

For Modules using the older Coolrunner CPLDs Philips PZ3064A or Xilinx XCR3064A (D.Module.VC33 Rev.1 (before Oct. 2001) and D.Module.21065 Rev. 1) download ISE WebPack Version 3.3WP8.1 from Xilinx

For all other modules (using Xilinx Coolrunner -XL or XC9500XL CPLDs), download the latest ISE WebPack Version from Xilinx . Make sure to install the latest available service packs and patches.

This is a typical optimization problem. The C programming language does not natively support the parallel instruction execution which is one of the main characteristics of a DSP. To exploit the potential of a DSP despite programming in C, all manufacturers provide optimizing compilers, using techniques like loop unrolling, instruction rearrangement, and memory access minimization. These optimization strategies might lead to undesired results, if the purpose of an instruction is not clearly visible to the optimizer. Typical examples are delay loops:

  int i;
  for (i=0; i<1000; i++); 

The optimizer cannot determine the use of this instruction, apart from assigning 1000 to variable i. You must explicitly instruct the compiler to keep this code by specifying i as volatile. Volatile tells the compiler that i may be changed externally, so i will not be held in a register, but in memory, and the optimizer will never delete any instruction using i.

  volatile int i;
  for (i=0; i<1000; i++); 

Volatile declarations are also extremely important if you want to wait for an external event using busy-polling. As an example, consider waiting for an A/D converter to complete. The A/D converter is memory mapped to the DSP. You read the state of the conversion from the busy bit in a status register:

  while (*(int *)ADC_STATUS_ADDR & BUSY) ; 

Since the optimizer will try to minimize memory accesses, the status register is only read once, and the program will typically stick in the loop. The instruction must be rewritten to

  while (*(volatile int *)ADC_STATUS_ADDR & BUSY) ; 

External memory access performance of TMS320C671x-based modules can be significantly improved by using the processor's cache. The cache operates in two levels, L1 and L2.

The L1 cache (4 Kbytes data and 4 Kbytes code) is always active. To enable caching for external memory, the corresponding MAR (memory attribute registers) must be configured. Each MAR controls a 16 MByte space of external memory. On the D.Module.C671x, SBSRAM is controlled by MAR0, and SDRAM by MAR12. To enable caching of these memories write a 1 to MAR0 and/or MAR12.

The L2 cache further improves performance and is enabled and configured in the CCFG (cache configuration register). L2 can be configured to 1-way (16 KBytes), 2-way (32 Kbytes), 3-way (48 Kbytes) or 4-way (64 Kbytes). L2-cache shares memory with direct mapped internal memory. The more cache is used, the less direct mapped internal memory is available. The best suitable configuration depends on your program structure. If for example data and coefficient fields are located in external memory, a 2-way cache should be used, so that both data and coefficient address ranges can be cached simultaneously. If only program code is located externally, a 1-way cache is often sufficient. A 3-way or even 4-way cache should be used if data, coefficients and code are located in external memory.

Care must be taken to ensure cache consistency if EDMA is used in external memory. The cache controller keeps track of CPU accesses and invalidates or flushes the cache if necessary. If however data is modified by EDMA transfers the cache controller is not aware of data changes and the cache lines will not be updated or flushed.
A typical example is DMA'ing McBSP data into external memory: Since the cache controller does not know that data has been modified it will not invalidate the affected cache lines, and the CPU will process outdated "old" data. You must invalidate the affected cache lines manually before processing the data.
The same will happen if the CPU updates a data block which will be DMA'ed to the McBSP later. If the entire block is cached the CPU will only manipulate the data in cache, the external memory itself will remain unchanged. A manual cache flush is required before starting a DMA from cached external memory.

The debugger is affected by the cache configuration too. The debugger always displays the cache content, not the "real" memory content. If you want to verify that data in SDRAM has been updated properly after a cache flush you must display an uncached mirror image of the SDRAM:
On the D.Module.C671x, SDRAM is located at 0xB000.0000 to 0xB0FF.FFFF. This memory area is cached if MAR12 is set to 1. The SDRAM appears as mirror images in the entire area from 0xB100.0000 to 0xBFFF.FFFF, e.g. at 0xB100.0000..0xB1FF.FFFF. As long as MAR13 is not set to '1', this mirror image is not cached, and the debugger will show the "real" SDRAM content.

For a detailed discussion of the cache please refer to the Texas Instruments application notes spru609 and spru656.