This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: TMS320C6713B
Tool/software: Code Composer Studio
I've inherited a DSP project and code base from a contractor/vendor and I'm working at maintaining it and also trying to update it where/when possible. To add a wrinkle, the project is based on Telelogic (now IBM) Rhapsody v7.1.1. My vendor had a custom adapter written to adapt the Rhapsody OXF framework to TI DSP/BIOS.
We're currently using CCSv3.3 with a Blackhawk USB560M emulator/debugger. The Blackhawk drivers for CCSv3.3 are limited to 32-bit Windows. CCSv3.3 also needs admin privileges to run on a modern Windows 7 machine (compatibility mode issues???), which is not going to happen in a corporate networked environment. We've been able to get by on a standalone machine but we'd like to upgrade the setup. We also have access to CCSv5.3 on another machine that we were using for Stellaris and Tiva development. I understand that newer versions of CCS prefer newer versions of DSP/BIOS. We currently have DSP/BIOS v5.42.01.09 in our CCSv5.3 setup.
Unfortunately, it seems that the Rhapsody OXF adapter may be tied to certain features of older DSP/BIOS versions. I've tried to rebuild the libraries against newer BIOS versions but that hasn't helped. The Rhapsody library provides the actual main() function while a timain() function in the Rhapsody-generated code base starts the main task threads. Some of the features we're using in our TCF file include 1 hardware interrupt, a user init function, several timer interrupts, and a custom memory layout: on-chip RAM, off-chip flash (code), off-chip SRAM (heap space as well as code/data) , off-chip NVRAM (data), and a FPGA that is configured to appear as memory-mapped IO.
Unfortunately, due to the project's nature (defense), I won't be able to post the .tcf and .tci files.
When we first tried to transfer the setup to our lab, an error occurred while parsing/compiling the .tcf file. This turned out to be an error in the DSP/BIOS 5.31 that came with our CCS setup. I tried 5.33.06 next and it compiled but did not run. I spoke to the vendor's developer and he told me that they had used 5.32.04 and I've been using that ever since. I've tried rebuilding Rhapsody libraries but still encounter runtime issues with newer DSP/BIOS versions. Trying 5.42.01.09 also cause similar issues.
On the compiler side things are less sensitive. I've worked with v6.0 and v6.1 compilers on CCSv3.3 and both 7.4.4 and 7.4.6 work on CCSv5.3 once DSP/BIOS 5.32 was installed.
I guess my questions are: is it worth updating to a newer DSP/BIOS version for better compatibility with CCSv5.3? Are there any common snags or pitfalls I may have missed? Any BIOS changes I'm unaware of?
Search for answers, Ask a question, click Resolved when complete, Help others, Learn more.
In reply to RandyP:
Thanks for replying Randy.
I guess the Rhapsody framework gave the original developer an OS-independent framework to build a statechart and event handling system to implement the required functionality. The originally prototyped on Windows using Rhapsody animations, then done on a DSK6713 (Phase 1), and finally migrated to a custom board that we are using now (Phase 2). As they were replicating a system with known behavior and known interfaces (rewrite of a legacy assembly language code base for a 16-bit chip), it probably helped with rapid prototyping. It definitely had a steep learning curve for me trying to understand the different types of statechart classes and synchronous vs asynchronous events. Also their board implementation had a mechanism where the MCU on the board could trigger a hardware interrupt on the DSP, but they hadn't implemented it in DSP software. It took me while to figure out that the HWI enable function needed to be in main()* and main() was actually in the Rhapsody OXF libraries so I had to modify them and rebuild. My main thread was started in "timain()" which was called by the library main.
As far as networking vs. standalone. The Rhapsody installation is network licensed so it needs to be on a networked machine. While CCSv3.3 won't run on that machine, the command line compiler tools work with the Rhapsody generated Makefile. I can then sneakernet it over via CD-RW/DVD-RW (we can't use USB sticks here) for JTAG or Flash programming. What I want to do is consolidate stand alone machines rather than maintaining a 32-bit machine with CCSv3 and a 64-bit machine with CCSv5.
We misplaced our JTAG header so I can't debug the setup at the moment. I can only program flash via serial port. But are there strategic locations I can/should add debugging info to find this runtime error once I get a new header (main, primary task thread, user init)?
Is there anything I can examine in the generated *.cmd file. I noticed that there are differences between the generated .cmd files from each BIOS version. Also our .tcf calls utils.loadPlatform("ti.platforms.generic", params); In the bios folder for 5.32.04 there are multiple files in the packages/ti/.../generic folder including the Platform.tcp. But on 5.33 and later there's only the tcp file. Is that significant?
*=Is this correct? HWI enables should be in main() (called after BIOS_init() and before BIOS_start())? It wouldn't work if I called it in timain() or the user init function. It works now but is there a better way.
In reply to Buried inDSP:
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.