• Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 1299 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

printf snprintf CCS v5.3

Avi W
Expert 1345 points
Other Parts Discussed in Thread: SIMPLICITI, CC1120, MSP430F5437A

Hello,
I'm posting this in "StarterWare" & "Low Power RF Tools" and here since I'm not sure where would be the correct location. 

I'm using simpliciti stack with MSP430F5437A host (yes we use CC1120 as transceiver).
Using CCS v5.3.0.00090.
The project stack is 400 Byte & heap is 0x400 as advised in tips for using printf.

I have a function in a file with the name test.c the function has C functions like sprintf/snprintf in it. 
It works OK.
Yesterday I've added a very close function to test.c which uses  the same code with different values. 

Both functions are called from same location in same flow, both functions input is (mrfiPacket_t *)
In the original functions the ptr doesn't change, in the new function it changes during the first sprintf or snprintf call. 

Currently I'm working on a workaround like this but... 
I would really like to understand & learn more about this. 

Best regards.

  • TI__Guru**** 173310 points

    Avi W said:

    Both functions are called from same location in same flow, both functions input is (mrfiPacket_t *)
    In the original functions the ptr doesn't change, in the new function it changes during the first sprintf or snprintf call. 

    I'm not really sure I understand what you mean. Can you please elaborate? Does the sprintf not print out correctly in the second function while it does in the first?

    Are you printing ints or floats? If you are using floats, check the --printf_support option in your compiler settings. This defaults to minimal for MSP430 projects, so you may need to modify it if you are working with floats.
    http://processors.wiki.ti.com/index.php/Printf_support_for_MSP430_CCSTUDIO_compiler

    Also depending on the amount of C I/O code, you may need to increase heap and stack sizes even more.

  • in reply to AartiG
    Expert 1345 points

    Thank you for your replay.
    I have found a workaround using the existed function that behaves OK. 

    I'm not printing floats. 
    After farther investigating it, it seems like after calling from the corrupted section to another function the return from the functions isn't behaving as expected & returning from the called function with corrupted stack & to the wrong IP (Instruction Pointer).

    f1(..);
a=1;
b=2;

    so after calling to f1 the return from f1 is returning to b=2.
    Is there an errata for MSP430F5437A on returning from functions?? [I didn't have the time to fully check]

    I haven't spent enough time on this so I haven't ruled out bugs in interrupt handlers. 
    Hope to have some time to dig into it soon since this is VERY interesting.

    If you have ideas how to proceed I'll be happy to hear/learn :) 

  • in reply to Avi W
    TI__Guru**** 173310 points

    Avi W said:

    so after calling to f1 the return from f1 is returning to b=2.
    Is there an errata for MSP430F5437A on returning from functions?? [I didn't have the time to fully check]

    I haven't spent enough time on this so I haven't ruled out bugs in interrupt handlers. 
    Hope to have some time to dig into it soon since this is VERY interesting.

    The first step would be to narrow down if there is a bug in the toolset (compiler) or in the device. You mention using CCS 5.3 which is now a pretty old version. My first suggestion would be to update to the latest version of CCS (6.0.1). http://processors.wiki.ti.com/index.php/Download_CCS

    That would come with the latest version of compiler tools, so if there was a bug in the compiler it will most likely be fixed. Once again make sure that you have sufficient stack and heap sizes set in the linker options. If the issue still persists in the latest version of CCS you may need to do some further debugging (by stepping through the code in the debugger) so see exactly where/why the function returns are not working as expected.

  • in reply to Avi W
    Guru 92251 points

    AartiG said:
    Once again make sure that you have sufficient stack and heap sizes set in the linker options.

    Avi W said:
    If you have ideas how to proceed I'll be happy to hear/learn :) 
    My experience is that insufficient heap doesn't cause corruption, but instead insufficient heap can cause printf() to fail to produce any output.

    However, insufficient stack can cause corruption. http://processors.wiki.ti.com/index.php/Stack_issues#Finding_out_static_stack_usage describes how to statically determine the worse case stack usage, to determine what stack size should be set in the linker options.