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.

DSP/BIOS 4.9 to 5.3 upgrade issues in DSP28x

Other Parts Discussed in Thread: TMS320F2812

I am trying to upgrade from DSP/BIOS 4.9 to 5.31.02. The application is for TMS320F2812, using CCS 3.3 and the BlackHawk USB2000 emulator pod.

 

I have reworked about 30 test harnesses I have for the project to run with DSP/BIOS 5.31.02, and they run ok. Unfortunately, the main application crashes after about 3 seconds. It is more complicated than the individual test harnesses by quite a lot, so something could be wrong in the configuration.

 

I had written my own files to use TCONF prior to the change in DSP/BIOS 5.3 to generate the configuration from .tcf instead of .cdb. I have hand-modified my configuration files, as well as tried a configuration created by the automatic translation tool (cdb2tcf.exe). Neither works.

 

I am a bit tight on SARAM space. All indications are that the 4.9 version had plenty of time to run, but the code analysis tools have never seemed to provide useful information with complicated applications. One change for 5.31 is that it insists on having a heap allocated. I was not using a heap before. How big does it need to be for 5.31? I accepted recommended default or 200 MAMUs.

 

One thing that would be helpful would be a list of the changes from DSP/BIOS 4.9 to 5.3, which I can’t seem to find on the web site.

 

What is the recommended most stable version of DSP/BIOS with CCS 3.3 for DSP28x family? My information is that 5.31 is suggested for “legacy” ISA. Does DSP2812 count as “legacy”?

 

Also, I cannot find a TMS320C28x DSP/BIOS API Reference for versions beyond 4.9.

Thanks, jdg

  • Hi Jeff,

    Here's the link to the 28x API for DSP/BIOS 5.33.02.    

    The release notes in 5.33.02 contain a link to "documentation index", if you click on that link you will be directed to a list of documents.  The 28x API guide will be listed.  Here is a direct link as well.

    http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/bios/bios_5_31/sabios-h08/docs/index_bios_manuals.html

    The list of changes are from 5.10 to 5.33.02 are listed in the release notes.  If you scroll down you will see the list of changes for each release.

    http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/bios/bios_5_31/sabios-h08/docs/release_notes.html

    I wanted to get you started.  Another person here will chime in to gather more information and help with answers to your other questions.

    -Jon

  • Jeff Geisler said:
    One change for 5.31 is that it insists on having a heap allocated. I was not using a heap before.

    This is news to me.   You can't going into the MEM properties and set the heap size to 0?  I spend more time on c5000 and c6000 but I've never seen a requirement for heap unless of course you're doing dynamic memory allocation.

    Jeff Geisler said:
    What is the recommended most stable version of DSP/BIOS with CCS 3.3 for DSP28x family? My information is that 5.31 is suggested for “legacy” ISA. Does DSP2812 count as “legacy”?

    I generally recommend that customers use the latest version of DSP/BIOS.  Currently we're on 5.41.10:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/dspbios/index.html

     

  • Thanks for the links. I had seen these before; I just wanted to make sure I wasn't missing something.

    By the way the link to "Knowledge base with known 4.90 to 5.X upgrade issues" in DSP/BIOS 5.31.02 Release Notes doesn't work - it complains knowledge base isn't running.

    The tip of literature for 28x family (API ref for 28x) is 5.31, so that's one reason why I am reluctant to upgrade to 5.4.

    The really odd thing is that I have about 30 smallish programs all working, but the main application and another smaller integration test do not work. I was originally using tconf and creating DSP/BIOS entities programmatically, and have made all my changes by reverse engineering what the tool does. Could there be an issue in the conversion utility?

    The reason I think DSP/BIOS 5.3 requires heaps is that the cdb2tcf utility sticks them in whether you had them or not, e.g.

    (I've tried 0 length heaps but it doesn't work any better.)

    /* enabling DSP/BIOS components */

     


    bios
    .GBL.ENABLEINST = true;
    bios
    .
    MEM.NOMEMORYHEAPS = false;
    bios
    .
    RTDX.ENABLERTDX = true;
    bios
    .
    HST.HOSTLINKTYPE = "RTDX";
    bios
    .
    TSK.ENABLETSK = true;
    bios
    .
    GBL.ENABLEALLTRC = true;

    bios
    .
    M0SARAM.createHeap = true;
    bios
    .
    M0SARAM.heapSize = 0x0200;

    bios
    .
    L0SARAM.createHeap = true;
    bios
    .
    L0SARAM.heapSize = 0x0200;

    bios
    .
    MEM.BIOSOBJSEG = prog.get("L0SARAM");
    bios
    .
    MEM.MALLOCSEG = prog.get("L0SARAM");
    bios
    .
    TSK.STACKSEG = prog.get("L0SARAM");

     

  • Thanks for the links. I had seen these before; I just wanted to make sure I wasn't missing something.

    By the way the link to "Knowledge base with known 4.90 to 5.X upgrade issues" in DSP/BIOS 5.31.02 Release Notes doesn't work - it complains knowledge base isn't running.

    The tip of literature for 28x family (API ref for 28x) is 5.31, so that's one reason why I am reluctant to upgrade to 5.4.

    The really odd thing is that I have about 30 smallish programs all working, but the main application and another smaller integration test do not work. I was originally using tconf and creating DSP/BIOS entities programmatically, and have made all my changes by reverse engineering what the tool does. Could there be an issue in the conversion utility?

    The reason I think DSP/BIOS 5.3 requires heaps is that the cdb2tcf utility sticks them in whether you had them or not, e.g.

    (I've tried 0 length heaps but it doesn't work any better.)

    /* enabling DSP/BIOS components */

     


    bios
    .GBL.ENABLEINST = true;
    bios
    .
    MEM.NOMEMORYHEAPS = false;
    bios
    .
    RTDX.ENABLERTDX = true;
    bios
    .
    HST.HOSTLINKTYPE = "RTDX";
    bios
    .
    TSK.ENABLETSK = true;
    bios
    .
    GBL.ENABLEALLTRC = true;

    bios
    .
    M0SARAM.createHeap = true;
    bios
    .
    M0SARAM.heapSize = 0x0200;

    bios
    .
    L0SARAM.createHeap = true;
    bios
    .
    L0SARAM.heapSize = 0x0200;

    bios
    .
    MEM.BIOSOBJSEG = prog.get("L0SARAM");
    bios
    .
    MEM.MALLOCSEG = prog.get("L0SARAM");
    bios
    .
    TSK.STACKSEG = prog.get("L0SARAM");

     

  • Jeff,
    have you tried setting bios.MEM.NOMEMORYHEAPS to 'true'. That should disable all heaps, but just in case you may want to comment out the four statements that configure heap in M0SARAM and L0SARAM, and the next two that configure BIOSOBJSEG and MALLOCSEG.

  • BIOS ships with its documentation in the "docs" directory.  I just double-checked and 5.41 comes specifically with a F28x API Guide.

  • Thanks Brad, I'll consider upgrade, once this is working.

    Sasha, I'll try your recommendation. My concern was whether DSP/BIOS 5.X required heaps for its own purposes. Seems like something I read in the documentation while trying to debug this suggested that was the case.

    jdg

    P.S. sorry about the double post - site slower than I expected.

  • So, the reason I think you have to have heaps is that, in the dialog you get when you start a New DSP/BIOS Config, it tells you that you must have dynamic memory heaps if you want the TSK Manager. Since I am using TSKs, seems like I can't turn them off. Hence my question about what DSP/BIOS needs them for. In particular, how big does the heap need to be, and would the kernel throw an exception if it couldn't get memory? I don't need heaps for my code, but don't want to do something that introduces subtle errors in the OS.

    Interestingly, I have made some progress by re-creating my (non-working) project from scratch using the visual configuration tool. Note that allowing the cdb2tcf tool to generate the tcf automatically did not work. There was not an obvious difference in a quick look; I'll go through line by line and see if there is some explanation.

    jdg

  • Jeff Geisler said:
    when you start a New DSP/BIOS Config, it tells you that you must have dynamic memory heaps if you want the TSK Manager.

    Can you post a screenshot or give an exact quote?  Heaps are not required for the TSK manager.

    I don't generally work on c2000 so I don't have the right things installed in CCS to do a quick test.

  • 6201.File-New-DspBios Configuration.pdf

     

    Dialog box from File | New | DspBios Configuration. the CTRL0700-0321 is my base board and is very simple, based on the ezdsp2812 configuration. The last check box says "TSK Manager (Requires Dynamic Memory Heaps)." Seems like the tconf tool also may enforce this; to be sure, you have to set bios.MEM.BIOSOBJSEG and bios.MEM.MALLOCSEG to something other than MEM_NULL, but perhaps only if bios.MEM.NOMEMORYHEAPS is set false.

    While I left the dynamic memory heaps in, I did disable RTA and RTDX when I configured my project from scratch. I recall that RTDX in particular has given my heartburn in the past. It was unavaiable when DSP/BIOS was first released for 2812 back in 2001 or so. When it did come out, I got a Spectrum Digital USB560 emulator, but was not able to get RTDX working with that in anything but the most trivial programs. Since you don't work with the 28X you may not be able to answer the question, but am I right to doubt the trustworthiness of RTDX in 2812?

    jdg

  • I'm using CCS 5.1 with DSP/BIOS 5.41.10.   When I create a new tcf for f2812 here's the corresponding screen capture:

     Here's my resulting tcf:

    F2812.tcf said:

    utils.loadPlatform("ti.platforms.ezdsp2812");

    /* The following DSP/BIOS Features are enabled.  */
    bios.enableRealTimeAnalysis(prog);
    bios.enableRtdx(prog);
    bios.enableTskManager(prog);

    // !GRAPHICAL_CONFIG_TOOL_SCRIPT_INSERT_POINT!

    prog.gen(); 

     

     You are correct that RTDX is flaky.  It's still around but no longer officially supported.

  • I'm using CCS 3.3.81.6. Probably explains the difference in the suggestion for heaps if you are using the TSK manager. Since you say DSP/BIOS doesn't itself require heaps, I will try without.

    If RTDX is flaky, is there something better I should be using? I've gotten by without it...

    Thanks,

    jdg

  • Jeff Geisler said:

    If RTDX is flaky, is there something better I should be using? I've gotten by without it...

    There's no replacement for DSP/BIOS.  There's something on the horizon for SYS/BIOS.  I believe it's currently available for our c667x DSPs.  I don't know the timeline for when it will roll out to other device families.  I imagine it will take a while since it's not the highest priority.