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.

CCS/TMS320F28075: Changed code, and now board does not work after resetting power or flashing through UniFlash

Part Number: TMS320F28075
Other Parts Discussed in Thread: UNIFLASH, SYSBIOS

Tool/software: Code Composer Studio

I have recently had to modify a project to change it from running off of SYS/BIOS tasks to instead run off of cpu timers. Because of this, I had to change a lot of code, and so am not sure what parts are relevant to post. The issue is that the new code works perfectly when run in debug mode through a XDS110, but as soon as I reset the power or try to run through UniFlash (which is how we have been sharing the files to other teammates) the board no longer runs properly. Of course, because it is no longer in debug mode, it is also much harder for me to even tell what is going on.

I am almost certain it is something to do with the code, as even if I do not touch the hardware at all, I can send the old .out file from before my changes through UniFlash and it works perfectly fine. Then, immediately when sending my new .out file, it no longer does. I am happy to post any code snippets that would help, I am just not sure which ones are relevant to this topic. Also, I am using the boot option to use GPIO pins 72 and 84 and pulling them high to use flash to boot, if that matters. 

  • Fred,

    Thanks for reaching out to the E2E forums.  Do you know if you have recently switch from COFF to EABI in the project settings(from old to new)?  If you right click on the project and select "properties" at the bottom you should look at the output format to see which is selected(I've included a screen shot to show this window"

    The reason I ask is that EABI has a different default for initializing variables than COFF; in that it does run time init on everything.  In cases where folks were using COFF this results in a significant amount time delta during the init which can time out the watchdog.

    I'll let you check this first, and depending on your reply we can proceed accordingly.

    Best,

    Matthew

  • Hey Matthew, thanks so much for getting back to me. I just checked, and it is set to "legacy COFF", and I believe this is the setting it was set to throughout the life of this project. 

  • Fred,

    Can you take a look at this thread, specifically the post that got marked as resolved?  There is some delay function that needs to be ran from RAM, vs Flash.  I'm looking for unique things about integrating BIOS that may be tripping us up.

    Best,

    Matthew

  • Hey Matt,

    So I actually stumbled into the answer this morning, so I will mark this question as resolved, but I am not really sure as to why this behavior is happening, so I would be very happy for some insight from you as to why this fixed my issue. The following code was included in the app.cfg file when we were using the SYS/BIOS, but I disabled it as I wanted to enable the timers within my code. Having it disabled seems to work completely fine for running off of the IDE but somehow it is necessary for UniFlash and power cycling? 

    var ti_sysbios_family_c28_Timer0Params = new ti_sysbios_family_c28_Timer.Params();
    ti_sysbios_family_c28_Timer0Params.instance.name = "ti_sysbios_family_c28_Timer0";
    ti_sysbios_family_c28_Timer0Params.period = 10000;
    ti_sysbios_family_c28_Timer0Params.prescale = null;
    Clock.tickPeriod = 100;
    BIOS.cpuFreq.lo = 150000000;
    BIOS.clockEnabled = true;
    Boot.OSCCLKSRCSEL = Boot.OscClk_INTOSC2;
    Boot.SPLLIMULT = 30;
    Boot.disableWatchdog = true;
    Boot.SYSCLKDIVSEL = 1;
    var clock0Params = new Clock.Params();
    clock0Params.instance.name = "clock0";
    clock0Params.period = 10;
    clock0Params.startFlag = true;
    Program.global.clock0 = Clock.create("&CLK0", 5000, clock0Params);

  • Did you remove SYS/BIOS entirely or just these particular lines? I'm wondering if you can try restoring them a few pieces at a time and narrow down what in particular is causing the issue.

    Boot.disableWatchdog = true seems like the most likely culprit. Do you disable the watchdog in main() now? It's possible that the boot and variable init is taking long enough that it's timing out before it's disabled or fed in the application code. Like Matt mentioned above, this is more frequent in EABI projects, but still possible in COFF.

    You could try connecting to the device after power cycling it. As long as you remove the GEL file from your target configuration, you should be able to connect without resetting the device, load the symbols from your .out (just the symbols, not the program), and see where the application is stuck.

    Whitney

  • Hey Whitney,

    You are completely right, it was in fact that line! I will try the fix mentioned in the thread Matt linked for a permanent solution, but am glad to know the issue. Thanks!