TMS320F28379D: Error #1558-D 64 bit floating point not allowed for sprintf

Hello Fred,

Can you show the console output and the line of code in reference? Are there any other errors or warnings that show up? Can you verify that the current project and any libraries included are built for FPU32 mode? Are there any 64-bit floating-point values in your code elsewhere?

Also, please take a look at this thread to see if any of the information there helps: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/905572/ccs-tms320f28388d-sprintf-floating-point-fails-on-cm-core

Good morning Omer. In response:

1) Console output:

"C:\\ti\\ccs1220\\ccs\\utils\\bin\\gmake" -k -j 4 all -O

Building file: "../vienna_main.c"
Invoking: C2000 Compiler
"C:/ti/ccs1220/ccs/tools/compiler/ti-cgt-c2000_22.6.0.LTS/bin/cl2000" -v28 -ml -mt --cla_support=cla1 --float_support=fpu32 --tmu_support=tmu0 --vcu_support=vcu2 -O1 --opt_for_speed=5 --fp_mode=relaxed --fp_reassoc=on --include_path="C:/Users/fred.schreiber/workspace_v12/pfc3phvienna_F2837x" --include_path="C:/Users/fred.schreiber/workspace_v12/pfc3phvienna_F2837x/device" --include_path="C:/ti/C2000Ware_DigitalPower_SDK_4_03_01_00/c2000ware/driverlib/f2837xd/driverlib" --include_path="C:/Users/fred.schreiber/workspace_v12/pfc3phvienna_F2837x/libraries/CLAmath" --include_path="C:/Users/fred.schreiber/workspace_v12/pfc3phvienna_F2837x/libraries/power_measurement" --include_path="C:/Users/fred.schreiber/workspace_v12/pfc3phvienna_F2837x/libraries/utilities" --include_path="C:/Users/fred.schreiber/workspace_v12/pfc3phvienna_F2837x/libraries/sfra" --include_path="C:/Users/fred.schreiber/workspace_v12/pfc3phvienna_F2837x/libraries/DCL" --include_path="C:/ti/C2000Ware_DigitalPower_SDK_4_03_01_00/solutions/tidm_1000/f2837x/drivers/include" --include_path="C:/ti/ccs1220/ccs/tools/compiler/ti-cgt-c2000_22.6.0.LTS/include" --define=CVN80 --define=CLA_DEBUG=1 --define=_DEBUG --define=_FLASH --define=F28x_DEVICE --define=CPU1 --define=LARGE_MODEL --define=debug -g --float_operations_allowed=32 --printf_support=full --diag_suppress=10063 --diag_suppress=173 --diag_warning=225 --diag_wrap=off --display_error_number --quiet --abi=eabi -k --asm_listing --preproc_with_compile --preproc_dependency="vienna_main.d_raw" "../vienna_main.c"

>> Compilation failure
subdir_rules.mk:26: recipe for target 'vienna_main.obj' failed
"../vienna_main.c", line 624 (col. 25): error #1558-D: 64-bit floating point operations are not allowed
"../vienna_main.c", line 624 (col. 25): error #1558-D: 64-bit floating point operations are not allowed
"../vienna_main.c", line 624 (col. 25): error #1558-D: 64-bit floating point operations are not allowed
"../vienna_main.c", line 624 (col. 25): error #1558-D: 64-bit floating point operations are not allowed
"../vienna_main.c", line 624 (col. 25): error #1558-D: 64-bit floating point operations are not allowed
"../vienna_main.c", line 624 (col. 25): error #1558-D: 64-bit floating point operations are not allowed
6 errors detected in the compilation of "../vienna_main.c".
gmake: *** [vienna_main.obj] Error 1
gmake: Target 'all' not remade because of errors.

**** Build Finished ****

No other errors or warnings

The source code line:

sprintf ((char*)xmit_buf, "X,%8.3f,%8.3f,%8.3f,%8.3f,%8.3f,%8.3f,**",
             VIENNA_guiV1_Volts, VIENNA_guiV2_Volts, VIENNA_guiV3_Volts,
             VIENNA_guiIL1_Amps, VIENNA_guiIL2_Amps, VIENNA_guiIL3_Amps);

Those VIENNA variables are all float32_t

******************************************************************

2) (FPU32) fpu32 is shown in Properties, under compiler -> processor options. Also, the main compiler window has a "summary of flags", and it includes --float_operations_allowed=32.

I can only assume the libraries used are built for 32 bit floating point. This is an old TI sample project that does a lot of floating point math.

*****************************************************************

3) 64 bit. I searched the project for double and for float64_t. They do not appear in any of the source code. That plus the fact that the properties are calling for 32 bit kind of indicates no 64 bit floats.

***********************************************************************

4) I looked at that link. It says the stack may need to be increased to support floating point with sprintf. That seems a little weird (was the stack just barely big enough before?), and also there are no stack errors shown. But just in case, can you give me a quick instruction on how to increase stack size? FYI under properties->C2000 Linker, the flags include --stack=0x380. Do I just increase that number? Or will all hell break loose if I do?

Fred Schreiber said:

The source code line:

I need something that I can replicate on my side, can you create an example as simple as the below snippet I have? I was able to build this without any errors.

#include <stdio.h>
#include <stdlib.h>

void main(void)
{
    float32_t temp = 8.0;
    char *transmit_buff;
    sprintf ((char*)transmit_buff, "X, %8.3f", temp);
    while(1);
}

Fred Schreiber said:

But just in case, can you give me a quick instruction on how to increase stack size? FYI under properties->C2000 Linker, the flags include --stack=0x380. Do I just increase that number? Or will all hell break loose if I do?

If you right-click on your project and select Project Properties, you can navigate to the following window and increase the size:

If you increase the number too much you will get an error stating so (the compiler and linker checks this sort of issue while allocating memory locations):

Hi again Omer,

I tried duplicating your small project. It builds with no compiler error. It does give one warning:

warning #10210-D: creating ".esysmem" section with default size of 0x400; use the -heap option to change the default size

I assume that means I might consider increasing the heap size, but the main point is it does allow the sprintf call. Here's my source file so you see exactly what I did:

/**
* main.c
*/
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(void)
{
float temp = 8.0;
char *xmit_buf;

xmit_buf = (char*)malloc(80);
sprintf (xmit_buf, "X = %8.3f\n", temp);

while (1);

}

I added the malloc call to get past a warning about using the xmit_buf before it was initialized. I also used a plain "float" type, since float32_t would require more #includes.

So it appears something in my main project is messing with sprintf. I don't remember if I mentioned this, but the project is taken from a TI sample named pfc3phvienna_F2837x.

I'm adding sprintf so I can build an ASCII message to send some important data out to an operator interface.

I found that "Basic" properties page and increased the stack size. The original was 0x380. I tried 0x400 and then 0x800. In both cases I still got the same floating point not allowed message. So I don't think the stack size is the problem.

Would it help if I send you all the compiler and linker flags? Any other ideas???

Hello Fred,

I'm not familiar with this example project, but if it compiles C code fine then it shouldn't be any different. The last debug step we can take is to swap in the different configurations one-by-one from your project to the slimmed down version. I know this may take a while to do, but this would be the most thorough way of determining where the compiler is acting differently. To simplify this, you can look at the C2000 Compiler and C2000 Linker settings in the Project Properties, find the differences, and change them one-by-one until you reproduce the same error.

If that doesn't work, the next step would be verifying the header files and file/library paths used (also in the Project Properties) to make sure everything is included properly.

Hello again Omer,

I went through the properties of the two projects, gradually adding compiler flags from the crashing project to the working one. I did find the cause. It's the "abi" flag. The new project uses --abi=eabi. The test project uses --abi=coffabi. The coffabi was assigned by default. I did not explicitly add it.

When I change coffabi to eabi, the test projects gets the "floating point not allowed" compiler error. Just for fun I tried coffabi in my real project, but the build aborted with a new error: "object files have incompatible formats". 

Unfortunately, I can't make any sense of this. ABI stands for application binary interface. The descriptions I've found say that all objects in a project have to be compatible, which I think explains why my project won't build with coffabi. No doubt the components of the baseline TI sample were built using the newer eabi.

What I don't understand is why the use of eabi disallows floating point op in sprintf  If the stdlo library was built with coffabi, I'd expect to see the incompatible formats error. Can you folks tell me why eabi causes this error? Is there a workaround?

Hello George,

Thanks for the suggestion. It makes sense. But I'm still new to CCS. The --float_operations_allowed=32 is part of the overall project properties. How to I customize the compiler properties for one file, but leave it in place for the rest of the project?

-fs

Fred Schreiber said:

How to I customize the compiler properties for one file

With the File Specific Options feature of CCS.

Thanks and regards,

-George

Part Number: TMS320F28379D

This is a follow-on to an earlier thread regarding compiler error 1558, floating point not supported for sprintf.

I was able to put the sprintf call into a separate file, and use file-specific options to remove the flag "float_operations_allowed=32".

That resolved the compiler error but the program still did not run. I found another E2E thread that suggested increasing stack size in order to use sprintf with floating point data.

I increased the stack by changing the linker .cmd file from:

RAMM1           : origin = 0x000400, length = 0x000400

to:

RAMM1           : origin = 0x000400, length = 0x001000

(later in the cmd file the stack is allocated to RAMM1 (.stack    :  > RAMM1    PAGE=1)

Those changes did not prevent the program from running. But when I actually changed the stack size in the project properties from 0x380 to 0x400, the program aborts shortly after startup.

I ran it in the debugger twice, and it got as far as two different locations before aborting with this error:

Breakpoint manager: Error enabling this function: This task cannot be accomplished with the existing AET resources.

At this point I don't know which rabbit hole to explore. Should I read up on "AET resources", or should I read up on Dos and Don'ts in linker cmd files.

I'll drag in my cmd file, and also the .map files for the two builds (stack=0x380 and stack=0x400).

Can you folks point me in the right direction?

Regarding:

Fred Schreiber said:

Breakpoint manager: Error enabling this function: This task cannot be accomplished with the existing AET resources.

At this point I don't know which rabbit hole to explore. Should I read up on "AET resources"

Please see:

https://dev.ti.com/tirex/explore/node?node=A__AFxRAHEqhlcitK5yopkNoA__ccs_devtools__FUz-xrs__LATEST

Hello Ki,

I don't really think this is a problem with the debugger, especially since I have not set up any watchpoints, event counters, or a profile clock. In fact the link you sent says software breakpoints do not use any resources.

Since this problem only occurs after I change the stack size from 0x380 to 0x400 in my linker properties, I have to believe there is something wrong in how I changed the stack size, or else some sort of conflict between the slightly larger stack and the way my memory is mapped out. Is there anything in the map files that indicate a problem?

Fred Schreiber said:

Since this problem only occurs after I change the stack size from 0x380 to 0x400 in my linker properties, I have to believe there is something wrong in how I changed the stack size, or else some sort of conflict between the slightly larger stack and the way my memory is mapped out. Is there anything in the map files that indicate a problem?

I can't comment on this. I just wanted to provide information on what the AET error meant.

Thank you Ki. I appreciate you responding so quickly. Is there someone else who can determine what I did wrong with sizing the stack?

Fred Schreiber said:

increased the stack by changing the linker .cmd file from:

RAMM1           : origin = 0x000400, length = 0x000400

to:

RAMM1           : origin = 0x000400, length = 0x001000

(later in the cmd file the stack is allocated to RAMM1 (.stack    :  > RAMM1    PAGE=1)

Note that you are not increasing the stack size here. What you are doing is modifying the specified RAMM1 memory range (which I would imagine is not recommended).

https://dev.ti.com/tirex/explore/node?node=A__APJQ1q8Ox6tOF4TmB4THeg__ccs_devtools__FUz-xrs__LATEST

Fred Schreiber said:

But when I actually changed the stack size in the project properties from 0x380 to 0x400

This is the proper way to increase the stack size.

RAMM1 is on-chip RAM block M1. I don't know how big this actual size is but it was originally set to length of 0x400. Perhaps you need to allocate the .stack section to a memory region with more space.

When you make this change ...

Fred Schreiber said:

changing the linker .cmd file from:

RAMM1           : origin = 0x000400, length = 0x000400

to:

RAMM1           : origin = 0x000400, length = 0x001000

... you have to be sure that memory is present in the actual system.  The linker, and related tools, blindly believe this specification is correct.  If it isn't, things just won't work, and there is no predicting what those things are.

With that in mind, make the stack as large as you can.  Just to see if that is the problem.

Please attach your linker map file to your next post.  So that the forum will accept that file, add the file extension .txt to it.

Thanks and regards,

-George

Fred Schreiber said:

but I would like to know where I can see a description of the on-chip memory layout. I have the Technical Referance Manual pdf file, but it doesn't have the RAM breakdown. If you guys could tell me where to find it, I'd appreciate that.

See page 179 of: https://www.ti.com/lit/ds/symlink/tms320f28375d.pdf