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.

CC3235SF: Need to rebuild SDK libraries to switch from fprintf to printf?

Part Number: CC3235SF
Other Parts Discussed in Thread: CODECOMPOSER

Champs,

Customer is asking:

I see that there is pretty high stack consumption of my tasks which is due to fprintf.

Do I need to rebuild SDK libraries if I want to use –printf_support option?

  " Level of printf/scanf support required(--printf_support)         "

Thanks,

/ Wolfgang

  • Hi Wolfgang,

    That flag would require rebuilding a library, but there are very few libraries that use printf directly unless there is a debug trace defined. The customer may want to check first if rebuilding the library would improve stack consumption.

    Best regards,

    Sarah

  • Hi Sarah,

    Thank you. I'll inform my customer.

    Best,

    / Wolfgang

  • I am asking because it looks that values provided by Stack Usage tool (from CodeComposer Studio) do not look to be valid.
    I get StackOverflow exceptions for some tasks even if stack size allocated to them is higher then value provided by StackUsage tool.

    I think it may be due to "xxxprintf()" - StackUsage reports a calls to vsnprintf(which consumes 30bytes each) and later on __TI_printfi() - with no value.

    When --printf_support option is not used - figures look completely different (values are higher) but at least (after adjustment of tasks stack to match values from StackUsage) I do not get exceptions.

    So I believe it may either be that linked library still use "full" version of sprintf or StackUsage measurement for "nofloat" is invalid. I have found following thread CCS/CC1310: Stack usage missing when --printf_support nofloat - Code Composer Studio forum - Code Composer StudioTm︎ - TI E2E support forums but it's 3 years old. There is event a bug report (CODEGEN-5179) but I cannot locate it in - Software Issue Report (SIR) (ti.com)

  • Hi Piotr,

    That thread is discussing that the stack usage tool is underreporting. I believe we switched external tracking tools since that thread was created, so it can now be found at EXT_EP-9037. Unfortunately, it is still in progress.

    While this bug does limit the effectiveness of the debug tool, it does not affect your application. Are you seeing stack overflow exceptions plus odd behavior in your application?

    Which linked library is using vsnprintf that you want to rebuild?

    Best regards,

    Sarah

  • Hi Sarah

    The roots of my original questions are following:

    I have four tasks in my system, each with own stack. When I found StackUsage tool I decided that I will optimize stacks allocated per each task.
    With default setting of compiler I noticed very high demands - so I decided to go with option --printf_support=nofloat.
    Values reported by StackUsage tool were much lower. I used that values and configured my OS tasks to them (+10%-20% margin of course).
    However after that I received StackOverflow exceptions.
    I thought that it could be caused by fact that I didn't recompile standard library - and that is why I asked main question.

    I studied more deeply documentation and now my understanding is that --printf_support=nofloat should not require rebuild of library it-self. I think it is well handled internally. And exceptions which I get are rather result of fact that values which StackUsage tool gives are underreported (fact that EXT_EP-9037 is still open would confirm that).

    So now questions are:

    - is it planned to fix StackUsage tool (and when)?
    - what is real stack usage of  __TI_printfi() - if I know it upfront could be a workaround. I could just add it (in my head :) ) to any values provided by StackUsage tool

    Best regards

    P.

  • Hi Piotr,

    There is currently not a timeline on the tool fix, although there have been some recent updates to the ticket.

    As for the exact size of __TI_printfi_nofloat, I would have to go find that information. Are you using the TI Arm Clang compiler?

    Best regards,

    Sarah

  • I use ti-cgt-arm_20.2.2.LTS - I think it's the one based on clang.

    BR
    P.

  • Hi Piotr,

    If you use the Runtime Object View tool in the debugger, does this give you a reliable stack peak? This tool monitors the stack during runtime versus analyzing the compiler, so it should avoid the bug with the StackUsage tool.

    Also, the ti-cgt-arm_20.2.2.LTS is the legacy TI Compiler. The current version of the TI Arm Clang compiler is ti-cgt-clang-arm_1.3.0.LTS. I recommend you take a look, as there have been many code optimization improvements, including to printf. You can find ticlang projects in the CC32xx SDK with updated linker files, plus there is a migration guide in the user's guide if you want to review all of the differences. If you have trouble importing a ticlang project from the SDK, see this FAQ.

    Best regards,

    Sarah

  • Hello

    I haven't yet been able to look at Clang based TI compiler.

    However I tried playing with ROV tool. From demos it looks to be pretty nice - however it looks that it supports only TI RTOS, doesn't it?

    But we need (and in fact want) to use FreeRTOS. Is there any way to get ROV working with FreeRTOS?

    Nevertheless if you are able to provide me (even a rough) stack consumption of __TI_printfi_nofloat()  in case of Legcy and Clang base compiler it would be more than enough for us to adjust StackUsage tool results.

    Thanks in advance.

  • Hi Piotr,

    ROV does support FreeRTOS; it was added in CCS v10.1.1 and CC32xx SDK 4.30 (there is one minor fix required for v4.30, if needed. v4.40 and later should work out of the box). The support is limited compared to TI-RTOS, but it will still help to identify stack peaks.

    I cannot find documentation for the exact size of __TI_printfi_nofloat. The next step would be creating a new thread to ask the tools team for assistance. If you use the "Ask a related question" button at the top of this page to create a new thread, I can make sure it is assigned properly.

    Best regards,

    Sarah

  • Question posted.

    In regards to ROV.
    I have version CCS v10.2.0 and CC32xx SDK v4.40.00.07 and I wasn't able to get it working.
    Do I need to add instrumentation/TI utils modules into code?

  • Hi Piotr,

    No, I imported a FreeRTOS example from SDK 4.40, built it, then started the debug session and opened the ROV from the Tools menu.

    Can you attach a screenshot of what is not working?

    Best regards,

    Sarah

  • Hi Piotr,

    I'm not sure if all the ROV features are supported, but you should be seeing "FreeRTOS" in the modules menu on the left, above "Monitor". That's where I'm able to see the task instances.

    What FreeRTOS version are you using? What XDC tools version?

    Best regards,

    Sarah