CCS/TMS320C6713B: upgrading DSP/BIOS on legacy design

Part Number: TMS320C6713B

Tool/software: Code Composer Studio

Hello all,

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?

  • Guru 82165 points
    Buried,

    If you have a TI sales person assigned to your company, please contact them. They may be able to facilitate file transfers, if needed. Not being able to see your work makes it very difficult to help you on specific debug issues.

    In general, the best thing to do on any new program is to be using the latest tools, which would mean TI-RTOS and CCSv7. TI-RTOS is the new name for SYS/BIOS, and SYS/BIOS was the update to DSP/BIOS with function name changes but the same basic functionality.

    But, you are using an older processor and more importantly are tied to a non-TI OS. I am not sure what all Rhapsody does for you, but it sounds like one bump on this path. CCSv7 does not require licensing, but you will want to be careful to check if your emulator will work with it. CCSv7 probably only supports EABI object file formats, while CCSv3.3 used COFF so your libraries would all have to be recompiled.

    "is it worth updating..." is a very subjective question, not a surprise to you, of course. My first thought, honestly, is that your job will 'mostly' be easier if you give up on the idea of updating all the way to a networked environment; stay offline and use USB sticks to transfer files - there should not be that many, and you should never need to move any files from the standalone machine to the networked machines, only the other way around. In any case, you would have to do some searching to find out if you can get CSv3.3 to run on the newer Windows versions, with a big issue for emulator drivers on a 64-bit PC.

    You have already encountered a few of the snags and pitfalls, and there will be more. We may have some experience-shedding threads on this forum worth you searching for. And try searching similarly at TI.com, where it will find E2E threads as well as documentation or papers about migrating to 64-bit and CCS versions.

    Not a lot of solid help here, but I wanted to start with my two cents worth.

    Regards,
    RandyP

    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:

    I just wanted to reply to this to share the resolution and close this out. I did some debugging with the 560M, CCSv5.3, and DSP/BIOS 5.4x once I found my JTAG headers. There was definitely memory corruption somewhere that prevented a proper backtrace and caused jumps to invalid code sections. Following Method 2 helped a little (processors.wiki.ti.com/.../DSP_BIOS_Debugging_Tips ) in that it would casue me to end up in a fault ISR but no backtrace.


    The first issue was in gbl_setL2cacheMode so I temporarily disabled the L2 cache. I fixed this later by increasing the OS stack in the .tcf to 0x2000 from 0x1024.

    The second issue was in Rhapsody initialization and changing the stack size of the main thread from 0x8000 to 0xA000 was enough to get things going again.