CCS/LAUNCHXL-F28379D: Unable to printf floating point numbers ????

Hello George,

I have had a lot if issues with STDIO in CCS. I hope its something I am doing because I would like it to work as it should.

Refer to a previous post.  

Compiler/TMS320F28379D: stdin not supported ??? - C2000 microcontrollers forum - C2000™︎ microcontrollers...

e2e.ti.com

Part Number: TMS320F28379D Tool/software: TI C/C++ Compiler After having no luck getting stdin to operate with the SCI so I did a lot of searching and have found

I was told that STDIN was not supported. 

Regardless I am unable to use printf on any floating point numbers. When debugging the code just hangs. I tried a while back and I have attempted it once again withe the same results.

I am not wanting to print on a CCS console but I want to direct it to SCIB. The re-direct for STDOUT is re-directing properly so printf should work fine.

It does work fine for integers just not floats.

You say it does work with floats. Can you send me a line of code using printf with floats? I cant get it working.

Here is a typical line of code - printf ("  FP N = %3.2f    ", HMI_RPM_f );

The target hangs and goes into the weeds when executed.

I do have the "printf_support=full" flag in the compiler flag section. Does this need to be in the linker flag instead or as well?

David Petryk said:

Here is a typical line of code - printf ("  FP N = %3.2f    ", HMI_RPM_f );

The target hangs and goes into the weeds when executed.

Please change that printf call to sprintf into a char array you know is big enough to contain the result.  Does that work?

Thanks and regards,

-George

Are you trying to print *floating point* or *fixed point*?

Unless you save it as a float or double you will have to write your own routine to print it. How is printf() supposed to know where to put the decimal?

Can you share some code?

Yes. I can share code. I can sent the entire project if you wish but in the meantime I will provide some screen grabs.

Here is the test code.

When the commented line is un-commented the output looks fine and prints "this is a message" as expected.

Then I comment the line as shown and let the floating point line execute the MCU looks like it is doing a watchdog timeout"printf support = full

or a very fast self reset somehow. I tried both a "sprintf" and "snprintf" i.as you suggested. The sn worked with the text message

and crashed with the floating point. The sn produced no output with the floating point. 

I would like to verify that I have the proper setup for "printf_support=full" flag set properly. Maybe I have goofed that up somehow and I really dont have full support enabled.  Is it a compiler and or linker flag? If the flag is not set properly would you expect the system to crash. I would not. IF I dont have FP support it should just produce no output and continue running IMO.

Here is a shot of my compiler flags.

And Just FYI here is a shot of my HMI screen as seen using TeraTerm.

I have a lot of places that need floating output format. I hope we can get this to work.

What is the type of HMI_RPM_f?

Your talk of fixed point and floating point confused me.

More info;

Just having the line with the floating point printf compile will cause the system to crash.

This behavior has been consistent ever I first tried to print floats. Now

I believe it has something to do with the flags.

David Petryk said:

I would like to verify that I have the proper setup for "printf_support=full" flag set properly.

You do.

David Petryk said:

Is it a compiler and or linker flag?

Compiler

Have you checked on whether the stack overflowed?

Thanks and regards,

-George

My stacks are set to 400 as suggested. I don't know how to check to see if they overflowed or not. Can you tell me how to check?

Its funny because when the offending line of code is simply compiled the error shows up. I have a break point set at the offending line of code but it never gets there. So it seems like the arror is not produced by the printf function being call at all.

More like something in the initialization part of the code that executes before main is executed.

ANy ideas on how to isolate where the problem is happening?

Here are some screen shots that looks like an overflow but I am not sure what the numbers are telling me.

I tried to double the stack & heap size to 0x800 but then I got an error that there was not enough room.

I have never understood how to allocate memory section. I assume the stack & heap are assigned to a specific sector. Can I change them to a larger sector?

Is there something I can do in the code to reduce stack usage?

I am in uncharted waters and not sure how to navigate my way to safe harbor.

OK George,

I have come more info for you. I looked at the "heavy users of stack space and showed the code and the usage bars together. As you can see the main offenders seem to be cursor related functions that simply print a half dozen characters to the serial port to move the cursor around. Some of these functions are not ever called but have a high usage. I am not understanding if these are the cause of the problem or not.

If I made these functions macros (embedded character strings) instead of called functions will that reduce the need for stack space? Does the number of times a function is called equate the the amount of stack space it needs?

One of the "yellow bars" is associated with a function that is never called. I wrote it and ended up not using it. Why is the stack usage so high? The implication is that functions in a program that are never used are still being included in the final output code. All the other compilers I have ever developed with will not include code that is never called but is present in the source files. Is that the case with CCS or does it include everything all the time?

Have a look at the functions and the stack usage in these screen shots. Let me know your thoughts.

OOPs - Turns out that I lied.

Doing some bug hunting and it turns out that the target hardware goes bonkers at the first execution of any "printf" that contains the floating point format.

It seems to be in any of the printf, sprinf or snprintf function calls that have the floating point format specified.

Of course I am not able to trace into that code to see if I can discover anything.

I am awaiting direction from you George on how to proceed from here.

Keith to answer your question about "What is the type of HMI_RPM_f?"

It is type float.

I have added 3 additional "replys" and they are not showing up.

I must be breaking somebody's rule.

This is soooooo frustrating.

I'll focus on a few things I think are most relevant.  

It appears you do overflow the stack.  If the linker option --stack_size is set to 0x400 words, then you definitely overflow it.  The stack usage view shows you need around 1200 words, which is more than 0x400 (1024) words.  The stack usage view comes from a static analysis of the code.  The interesting column is the last one, named inclusive size.  This shows the amount of stack required by that function, plus all the functions it calls.  The amount required by the startup function _c_int00 is the interesting one.

I'm not sure.  But it may be the case that the program you want to run does not fit on your system.

You should heed the linker warnings about creating an output section without a SECTIONS specification.  This means those output sections are allocated to memory according to the default algorithm, which is rarely correct.  Usually, the linker command file provided with the project handles all these details.  Thus, it is possible you use the wrong linker command file.  To pursue that possibility, I recommend you start a new thread in the C2000 device forum.  Or, if you prefer, I can move this thread into that forum.  

If you decide it is better to change the linker command file you started with, then please see the article TI Linker Command File Primer.

Thanks and regards,

-George

George, I am super confused.

Here is an example. I have a simple function that sends a few characters out the serial port "EL". It is called only once in my program and is not in a loop of any kind. Stack usage reports that it is overflowing. How is that possible?? Looking at the screen grab you will see only one instance of the call to EL which gets executed at program startup and never again. Also it shows Stack usage off the charts, and the source code for that function. The code could not be much simpler. I am at a loss as to why this function needs so much stack.

Earlier today when I was using compiler version 8.1.1 I had a function that was never called and it was also indicating that there was stack overflow. That's impossible. I have since upgraded to 8.12.0 and that issue went away magically. I am having a hard time believing what the compiler stack usage page is telling me.

Meanwhile I have a number of functions that are called tens of thousand times a second and their numbers are all less than 10. I don't understand. Is the stack requirements for any given function a matter of how often it gets called or how many call levels deep it is when it gets called. Can you explain how I have such huge difference. All the numbers are all "low" or really "high" nothing in between.

Are there some documents that explain this in detail?

As far as the section warnings, I agree with you - they should not be ignored. I just have not gotten around to solving that issue yet. The hardware is executing just fine and those warnings are a result of installing the DCL functions into my project of which I am using only one.

I also understand that the memory & sections & sectors and all that stuff needs to be managed. I have not yet delved into that as of yet. This is my first project using a TI processor and I have to say the learning curve is very steep.

I have also traced the root problem that has stirred up everything I just mentioned which is of course the "printf" of floats crashing.

I have traced the problem in the printf function itself. Here is where it never returns from a call to a function "__TI_printfi" I stepped through that function for a bit and I know its failing.

Here is where things seem to go south.

Anyway I would like to know if you guys can duplicate my 6 line program and see if it works? I am using a Launchpad XL f28379d board. I cant make it work for floats. It works for integers just fine so the printf function is half working. Maybe I am the only one one the globe that is trying to print floats in my specific set of hardware??

David Petryk said:

I have a simple function that sends a few characters out the serial port "EL". It is called only once in my program and is not in a loop of any kind. Stack usage reports that it is overflowing. How is that possible??

Perhaps it would help if I explained the difference between the Exclusive Size and Inclusive Size columns.  The Exclusive Size is the amount of stack required by that function, ignoring any functions it may call.  The Inclusive Size is the amount of stack required by that function, plus the amount of stack required by all the functions called by that function.  Note this is applied recursively.  So, if f1 calls f2, which calls f3, which calls f4, and so on, the amount of stack required by each of those functions is added in.  The function EL calls printf.  While EL requires very little stack, printf, and everything printf calls, requires lots of stack.

Using printf for a simple string does not activate the helper functions called by printf which require so much stack.  Using printf for a float does activate those helper functions, and that is when the stack actually overflows at runtime.  

Until you find a way to allocate at least 1200 words to the stack, you cannot print float values.

I recommend you try to get this short program to work ...

#include <stdio.h>

int main()
{
   printf("float test: %f\n", 3.14);
   return 0;
}

Thanks and regards,

-George

George Mock said:

I recommend you try to get this short program to work ...

Did you try?  If so, what happened?

Thanks and regards,

-George

Since it has been a while, I presume you have resolved your problem.  I'd appreciate hearing how you resolved it.

Thanks and regards,

-George

Hi George.

David Petryk said:

Is there some documentation about the structure of the linker file and all that secret stuff?

The best place to start is the article Linker Command File Primer.  

Thanks and regards,

-George

Since there has not been any activity recently, I will mark this thread closed for now.  If you post to the thread within 30 days, it automatically reopens.  At 30 days, the thread is automatically closed to future posts.  If that happens, then you can renew things by starting a new thread.

Thanks and regards,

-George