55x FAQ
From Texas Instruments Embedded Processors Wiki
Which applications are a good fit for 55x DSP
The 55x DSP core from TI combines low power with processing efficiency. It is capable of single-cycle dual-MAC and features excellent code density due to its variable length instruction set. It is a good fit in products that require a good mix of low power and solid performance.
What tools are available for development?
Development is usually done using the Code Composer Studio (CCS) integrated development environment (IDE). CCS comes bundled with the 55x compiler as well as a chip support library (CSL) and DSP library.
Typically an evaluation board is used for initial software development.
Several are available at the Spectrum Digital Support page under C5000 Family.
You can use the XDS100 with the 55x and Code Composer Studio v4
You can also write C55xx DSP core software by using the C55xx Simulators.
An example how to set CCSv41 for C5505 CPU Cycle Accurate Simulator can be found here
Q: What tools versions do you usually use for development of C5000 SW?
- A: As of Nov 28, 2011, the C5000 SW development team primarily use are:
- HW: 5515 EVM C5515#EVM
- SW: Code Composer Studio version 4.2.4 with compiler version 4.3.9 and DSP/BIOS version 5.41.10.36
- Note these are available from: DSP/BIOS Download Page and Compiler Releases
- A: Please check the release notes for the SW products you are using for tools versions.
- A: CCSv5 is now available, but the C5000 SW team has not transitioned to that version of the software. The plan is to move to this version of CCS in 2H12. At that time, an updated BIOS and compiler release will also be used.
Where can I find examples that will configure the DSP and its peripherals for off-chip communication?
Check out the C5000 Chip Support Library page for more information.
What are the CPU versions for the different Silicon versions of the C55x devices?
Please click here to see our application note on various Silicon versions, CPU versions and corresponding compile options to be used for the C55x devices.
Does 55x have a unified address map?
Sort of:
- Program/Data
- I/O (peripheral space)
The 55x has a unified address map in the sense that the code and data reside in the same physical RAM. However, that RAM is byte addressable for code and word (16 bit) addressable for data. See the "byte vs word" FAQ for more info.
What's the deal with byte addressing vs word addressing?
Bottom line:
- CPU data accesses are all word (16-bit) accesses, i.e. MAU=16-bit
- CPU program accesses are all byte (8-bit) accesses, i.e. MAU=8-bit
When accessing program space (i.e. CPU executing an instruction) it utilizes a byte address. When accessing data space (i.e. CPU reading a variable in RAM) it utilizes a 16-bit address. As an example let's consider the case of locating code at the beginning of the DARAM4 block on a 5502. This would correspond to byte address 0x8000. If instead we located a data array at that same place it would be accessed at address 0x4000 (i.e. byte_addr >> 1).
When I write my linker command file should I use byte addresses or word addresses?
Everything in the linker command file should use byte addresses.
The linker will then assign addresses based on whether it is code or data. Labels corresponding to code are given a byte address while labels corresponding to data are given a data address. This is shown in the map file which the linker outputs.
How do I access peripheral registers?
To access the peripheral address space you need to use the ioport keyword. This tells the compiler to generate the appropriate instructions to access I/O space.
volatile ioport unsigned short int* pDMACSR1; // declare pointer to DMACSR1 register pDMACSR1 = (unsigned short int*)0x0C23; // assign the register address to the pointer DMACSR1 = *pDMACSR1; // clears CSR (by reading it)
Why can I not correctly move data that spans a 64K-word boundary?
This applies to all devices that use the 55x Rev 2.x core (5510A, 5509A, 5507, 5506, 5503, 5502, 5501). The A-unit inside the CPU that does the arithmetic associated with any address mode only operates on the lower 16-bits of the address registers. For example, when doing an auto-increment of a 23-bit XARn it only modifies the 16-bit ARn portion of the register causing the address to wrap if crossing a 64K-word boundary.
Due to this hardware limitation, the linker generates an error if any data section (though not a code section) spans a 64k-word boundary. This protects the user against most cases where it would be an issue.
Resolving linker errors due to data spanning 64k-word boundaries
- Determine which section is causing an issue.
- Check the size of the section. If it is bigger than 64k words you will need to break up the section.
- If it is less than 64k you will need to force the linker to allocate the section inside a 64k-word aligned block. This can be achieved using the block keyword which will bump the section's start address up to the next aligned boundary if the section will not fit in the current block aligned to the given size. (Note that for sections greater than 64k words the block keyword merely forces the section to start on a 64k-word boundary, but since the section is greater than 64k of course this will not solve the problem.) Here is an example of how to use the block keyword:
.cinit: block(0x20000) {} > SARAM
Despite the fact that the linker actively tries to prevent this issue, there are still rare cases where this issue pops up. Generally this occurs when programmers start manually manipulating pointers to memory. In particular you might very well run into this issue if you are using memory overlays for run-time relocation of code. In that case you generally define load and run addresses in the linker command files and relocate the code at run-time (e.g. from external memory to internal memory). In this scenario your code in external memory or internal memory might very well span a 64k boundary. However, the linker will not give a warning because it's ok for code to span these boundaries. However, when you are in the process of copying the code from external memory to internal memory the code is actually being treated like data and so the 64k boundary issue can pop up.
Ways of working around the 64k boundary issue
- Use DMA to move the data.
- Write a less optimal copy function that is "boundary safe". For example, in Large or Huge Memory Model force address arithmetic to be done in more than 16 bits by casting the addresses to 32-bit integers, doing the arithmetic, and casting back to pointers to do the memory accesses.
{ uint32_t src, dst, x; ... // Copy CNT bytes without worrying about 64k boundaries for src and dst pointers for(x = 0; x < CNT; x++) { *(uint16_t*)dst++ = *(uint16_t*)src++; } }
How do I program the address of my data in the DMA?
The DMA "sees" memory as byte addresses, so if you are referencing an array you need to do appropriate shifting to give a byte address. For example, if you have declared an array data_buf[] and wanted to use it as a source address you would write code something like this:
// SET THE DMA SOURCE ADDRESSES dma0.dmacssal = (DMA_AdrPtr)(((unsigned long int)data_buf)<<1); dma0.dmacssau = (unsigned short int)(((unsigned long int)data_buf)>>15);
How do I change stack modes?
Short answer:
- Create a new interrupt vector table with the appropriate mode encoded into the reset vector.
- Modify IVPD/IVPH to point to that table.
- Execute a software reset instruction.
- See this example code.
Long answer:
The 55x has 3 stack modes as documented in Section 4.2 (Stack Configurations) of the 55x CPU Reference Guide. When the device comes out of reset the CPU registers IVPD and IVPH are set to 0xFFFF which causes them to fetch the reset vector from 0xFFFF00. That address corresponds to the boot ROM on devices shipping today. So the decision as to how the reset vector should be configured was made at the creation of the boot ROM. When the CPU comes out of reset and fetches that vector from the boot ROM the stack mode gets set.
You can create a new vector table and modify IVPD and IVPH to point to the vector table. However, in order for the CPU to "read" your stack configuration which is embedded in the reset vector you need to execute a soft reset. This will cause the CPU to branch to the address in the reset vector (e.g. _c_int00) and to set its stack mode based on the embedded value.
Why am I getting a bunch of linker errors such as, "can't find input file 'bios5510.a55'" when I build my BIOS project?
By default in CCS 3.3 when you create a new 55x project it will default to "small memory model". Also, when you create a new BIOS configuration for 55x it will also default to "small memory model". However, BIOS does not ship libraries for small memory model! To solve the issue you must change both your compiler options and your BIOS configuration to use "large memory model".
- Go to Project -> Build Options -> Compiler -> Advanced and select Memory Model as "Large (-ml)".
- In your BIOS configuration file (*.tcf) go to System -> Global Settings -> (right click) Properties. Choose Memory Model as LARGE.
Note that small memory model severely constrains your memory usage in that all data must be confined to a single 64k-word page. Whether you use BIOS or not it is generally a good idea to select the large memory model for your compiler build options.
As of BIOS 5.33.05 the new default for 55x configuration files is the large memory model. As of CCS 4.0 the new project default for 55x is also large memory model.
How are the bus keepers implemented on GPIO A.x lines and how do they work under different configurations?
Background: The C5500 EMIF is configured in Data-only mode. The GPIO A.x (EMIF address bus) lines are used to control external logic or peripherals. Applies to C5503, C5506, C5507, C5509A.
Answer: The buskeeper is implemented as shown in the diagram below. The resistor values are adjusted from device to device. This implementation is for the TMS320VC33 and is obtained from the data manual
The "main buffer" is a strong driver (mA range) that shown here controlled by the R/W-. The bus keeper is a weak driver (uA range) that is controlled here by the SHZ-.
Here is a truth table that defines how the bus keepers will operate:
SHZ- R/W- Internal External Data Bus Pin (w/o pull-up)
Data Bus
0 (BK disabled) 0 0 Driven to 0 by the main buffer
0 (BK disabled) 0 1 Driven to 1 by the main buffer
0 (BK disabled) 1 X Hi-Z (output voltage will go to some intermediate voltage between the rails)
1 (BK enabled) 0 0 Driven to 0 by the main buffer (bus keeper follows the main buffer)
1 (BK enabled) 0 1 Driven to 1 by the main buffer (bus keeper follows the main buffer)
1 (BK enabled) 1 X Bus keeper weakly holds the state of the pin at the last state that was
driven either by the main buffer or y the external world.
Can you show me some CCSv41 configurations?
An example how to set CCSv41 for C5505 CPU Cycle Accurate Simulator can be found here .
An example how to setup the C5505 USB Stick under CCSv41 can be found here .
How do I use Software Breakpoint (estop_1) to debug my code?
In addition to setting SW breakpoints in Code Composer Studio by double clicking on a line of code, there are some other uses for this feature. The SW breakpoint is actually an instruction that gets embedded in your application by CCS by swapping out the instruction where the BP is being set. This is why the SW breakpoint can only be used in RAM memory. The SW breakpoint instruction is ESTOP_1 in mnemonic or ESTOP_1() in algebraic (op code: 0x460c) which stands for emulation stop. Here are some additional uses you can make of this instruction:
- Embed instruction in your code to stop execution at a particular address. Works for RAM or Flash.
- Fill all unused memory in your system with the op code to make it easier to debug when execution does not flow as you intended. You can do this with the linker or by manually adding this in CCS with Memory Fill command. This technique only works in RAM memory.
What is the difference between the Small, Large and Huge memory models?
The memory model defines how data memory is accessed.
Small Memory Model: (rts55.lib) 16 bit data address is used for data access.
Large Memory Model: (rts55x.lib) 23-bit data address is used, but there is memory boundary limitation. The offset address should be within 64K. If offset address goes over 64K, it will be wrapped around.
Huge Memory Model: (rts55h.lib) 23-bit data address without the 64K boundary limit. For v3.x CPU only.
Is the Device Driver Kit (DDK) still supported for C5000?
Q: App note SPRA856 references a software package called Device Driver Kit (DDK). I can't locate this package. How can I find it?
A: The DDK is no longer supported for the C5000 family. It was based off an old version of DSP BIOS which has been superceded. The closest software we have today is the Chip Support Library (CSL). It is not full driver implementation like previous DDK. You can access the CSL package here: Chip Support Library down load page.
What does emulation error 0x80001240/-1062 mean? I get this trying to connect to target board
Typically, this message is generated when the emulator sees a low level on TVD pin of emulator JTAG interface. TVD is target voltage detect. Pin 5 on the 14-pin header, it might also be referred to as VTref. Essentially, this is the first thing that the emulator checks for and if there is no voltage detected, it considers the target to be unpowered.
Our Documentation calls for a 100 ohm current limiting resistor on TVD/VTref. For more details see:
If you have a larger pull-up on TVD rather than a small current limiting resistor the XDS may get confused. There have been cases with some emulators where a target board gets designed with the size of current limiting resister just at the right value (~1K ohms), where it will work sometimes and other times it will fail and report target voltage failure.
Why am I getting a "Syntax Error" and "Invalid Mnemonic Specified" when creating a new project on CCSv4 after including the CSL library?
In order to avoid such an error please rebuild CSL with the following compiler option enabled:
1) Go to "Runtime Model Options" tab in the C/C++ Build options of the project.
2) Check "Codegen outputs algebraic assembly".
3) Select assembly source language to "algebraic" instead of "mnemonic" which was a cause of the error you've got due to the source files of CSL was written using algebraic assembly.
4) Rebuid the project with the new parameters.
Assembly Code Review Checklist
C55 Assembly Code Review Checklist
Where can I find help for C55x Common Errors and Fixes?
See C55x_Common_Errors_and_Fixes
Is SYS/BIOS Supported on the 55x?
- There are no plans at this time for support of SYS/BIOS on the 55x. (Last updated October 2011).
- DSP/BIOS 5.xx is supported and used by a large majority of 55x customers.
Q: What Kind of Flash Memory can be used with the C55x?
- A: Please check the EVM or EZDSP reference designs.
- A: For 5515/5535 and similar parts you can use:
Related FAQs
General C55x DSP
- 55x_FAQ
- DSP Library FAQ
C5000 Device Families
C5000 Device Tools
- C5502 EVM FAQ
- C5502 eZdsp FAQ
- C5505 eZdsp FAQ
- C5505 EVM FAQ
- C5509A DSK/EVM FAQ
- C5509A eZdsp FAQ
- C5510 DSK FAQ
- C5515 eZdsp FAQ
- C5515 EVM FAQ
| For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article 55x FAQ here. |
