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/TMS320C6727: CCS3.3 and printf when loading programs from external flash.

Part Number: TMS320C6727

Tool/software: Code Composer Studio

Hello,

I am booting from external flash on a C6727. In the external flash I have a basic DSP/BIOS program that kicks off a task to blink an LED on our development board. This is working just fine, but, when connected through CCS3.3, I do not seem to get any (reliable) STDOUT output.

I am running a C++ program and have included the <cstdio> header file. I've also tried it with the stdout.h header file. I have also increased my stack size and heap size for the program by a few magnitudes to make sure I have a large amount of memory in the case that printf might be failing silently. 

Strangely, when I put a break point on calls to printf, they just get skipped over and the processor never hits the break point. Could this be an indication that something is missing? 

Do I need symbols to be loaded to properly get data sent to STDOUT printed in CCS3.3? Otherwise how would the debugger know where the _CIOBUF_ is located? 

Also, bonus question: I actually have two programs stored in flash. When a variable in the first program is set, it will load a secondary program into internal RAM (note that the first program is completely stored in our external SDRAM off the EMIF bus). I also have had trouble getting prints out from this second program, even after loading the symbols for this second program. Is it even possible for the debugger to locate a new _CIOBUF_ and properly get the prints from a second program? If so, is there some tips I need to do or CCS settings I need to change?

I know this is a lot of information, but I'm just wondering if there's really any secret to getting printfs to work reliably when booting from external flash. 

Thanks,

Vincent Galbo

  • Hello Vincent,
    Have you seen the below article? It covers a lot of the common issues:
    processors.wiki.ti.com/.../Tips_for_using_printf

    Please note the sections on the C I/O buffer and the breakpoints.

    Thanks
    ki
  • Yes, I have read that article actually.

    I was able to fix it, but I'm not sure I understand why. I'll give you an insight into my program setup and perhaps it will reveal something.

    It appears that I was maybe loading symbols too quickly to properly setup CCS or the debugger. Here's my GEL code that will notify one program (the ProjectTemplate) to begin loading the second program from flash (the GroundTest) and give that program control:

    hotmenu GroundTestMode()
    {
    GEL_Halt();
    GEL_SymbolLoad("..\\Debug\\ProjectTemplate.out");
    g_testMode = 1;
    GEL_SymbolLoad("..\\Debug\\GroundTest.out");
    GEL_Run();
    }

    Once the g_testMode variable is set in the ProjectTemplate, it will begin loading the GroundTest program from Flash and transfer control. However, this code did not work. I had to remove the immediate loading of the GroundTest symbols and allow the code to fully transfer to the new program and then load the symbols to get the output. So, for me, this new series of GEL calls works better:

    hotmenu GroundTestMode()
    {
    GEL_Halt();
    GEL_SymbolLoad("..\\Debug\\ProjectTemplate.out");
    g_testMode = 1;
    GEL_Run();
    }

    hotmenu LoadGroundTestSymbols() // This must be called after fully loading into the the GroundTest mode.
    {
    GEL_SymbolLoad("..\\Debug\\GroundTest.out");
    }

    I wonder if there's a way that I can more reliably and automatically load the symbols for the GroundTest program without having to have a user perform two GEL calls?

    Thanks,
    Vincent
  • Vincent Galbo said:
    It appears that I was maybe loading symbols too quickly to properly setup CCS or the debugger.

    you are running into a known limitation of GEL - not all GEL calls are synchronous in behavior. I can confirm that GEL_SymbolLoad is not synchronous. Hence when your make the call to GEL_SymbolLoad, the command to load the symbols will sent to the debugger and the GEL will move on to the next line to execute in the GEL script before the load is complete. This is likely the issue you are running into. 

    Vincent Galbo said:
    I wonder if there's a way that I can more reliably and automatically load the symbols for the GroundTest program without having to have a user perform two GEL calls?

    There is a GEL callback function called "OnFileLoaded". This function will be called after a program is loaded. I believe that is also the case for symbols loaded (not 100% sure). You can try implementing that function so that it checks if g_testMode=1 and if true, then load the symbols for GroundTest,out

    Thanks

    ki