Senior III

Solved

Does STM32CubeIDE and Azure RTOS properly support Sprintf?

Forum|Forum|2 years ago
April 17, 2024
20 replies
4869 views

I am having issues using sprintf in an application on a STM32H743 using Azure RTOS. The function works correctly the first time it is used to convert a float to a string but after the first use, it inserts garbage characters where the decimal point should be while the digits are as expected. The garbage characters continue to show up on subsequent calls to the routine where the sprintf is used and show up in other routines that use sprintf. The garbage characters are always the same and only appear for float values that have digits to the right of the decimal point. An example is when printing the conversion for the internal battery measurement which comes out as ...MCU Bat : 3.15 V on the first pass, then comes out as ...MCU Bat : 3"KOq@=xZ15 V on the second pass. It is repeatable. The format string is ...MCU Bat : %.2f V\r. Changing the format string does not seem to effect the result.

I have gone over numerous posts regarding sprintf and RTOS but none seems to match with what I have implimented and what I am seeing. There are no hard faults or crashing.

Version info:

STM32CubeIDE - Version: 1.14.1 - Build: 20064_20240111_1413 (UTC)

STM32CubeMX - STM32 Device Configuration Tool - Version: 6.10.0-RC9 - Build: 20231120-2037 (UTC)

Linux LMint 21

This topic has been closed for replies.

Best answer by GreenGuy

An an answer with solutions that work this is the summary.

I had to set Optimization to something other than none to get sprintf to work with floats correctly after ThreadX was instantiated. The other option is to avoid the use of floats by reducing floats to integer values before and after the decimal point and sprintf them separate with %d.%d.

I think this is a bug in the compiler since setting Optimization to none does something with the standard c library that affects its runtime code. So the above solutions are work arounds. It is noted that there are various valid complaints concerning the lack of reentrancy with respect to the standard C libraries that come with the CubeIDE toolset.

AScha.3

Super User

I would set in debug a breakpoint at the sprintf line , to look , what is the float now ; + whats in the string, after sprintf ; then run ..and look.

+

what did you set : in project settings ->

If you feel a post has answered your question, please click on " Best Answer ".

GreenGuyAuthor

Senior III

I guess I could uncheck the scanf option since it is not used. But that does not make a difference.

I already did the break point on the sprintf line. The float values are good and the string after the sprintf has the garbage characters in it. I also tried stepping into the sprintf function but it simply steps over it. The local string buffer is initialized to all 0 upon entering the routine containing the sprintf.

AScha.3

Super User

> I also tried stepping into the sprintf function but it simply steps over it.

Hm - whats your optimizer setting ?

+

Just for test: set D-cache off (or dont enable it ), to be sure its not just some ...cache effect.

If you feel a post has answered your question, please click on " Best Answer ".

GreenGuyAuthor

Senior III

maximum(g3)

Pavel A.

@GreenGuy Please test before starting the RTOS scheduler. If that works, you'll need to fix the multi-threading locks in newlib for ThreadX.

GreenGuyAuthor

Senior III

that will take a good deal of rearranging since I use threading to send the messages.

But it is worth a try to understand what is wrong with sprintf.

Right now my work around is to reduce every thing to non decimal by doing:

bat_left = (UINT)battery;

bat_right = (UINT)((battery - bat_left)*100); //2 decimal places

and then just building the message with %d.%d - no problems!

Pavel A.

>Right now my work around is to reduce every thing to non decimal by doing:

For the same effect you can try functions ecvt or fcvt (in stdlib.h)

> that will take a good deal of rearranging since I use threading to send the messages.

Not at all. Simply, add a small test function and call it immediately before MX_ThreadX_Init().

GreenGuyAuthorBest answer

Senior III

An an answer with solutions that work this is the summary.

I had to set Optimization to something other than none to get sprintf to work with floats correctly after ThreadX was instantiated. The other option is to avoid the use of floats by reducing floats to integer values before and after the decimal point and sprintf them separate with %d.%d.

I think this is a bug in the compiler since setting Optimization to none does something with the standard c library that affects its runtime code. So the above solutions are work arounds. It is noted that there are various valid complaints concerning the lack of reentrancy with respect to the standard C libraries that come with the CubeIDE toolset.

Pavel A.

> I had to set Optimization to something other than none to get sprintf to work with floats correctly after ThreadX was instantiated.

This sounds worrying, hints to a thread stack overflow or subtle timing issues.

> I think this is a bug in the compiler

8)

GreenGuyAuthor

Senior III

It is certain the code runs more than 2x faster even with -Og3. So ...timing? I know that I do not have stack problems since after sometime running and exercising the code containing the sprintf calls, the stacks are good by inspection. It is not possible to step the sprintf code. Using the dissassembly window is awful and many times I have tried to get a look at it, CubeIDE crashes out of the debugger back to the C perspective, terminating the debug terminal, if I scroll to far in the disassembly window.

I have IAR running and will be testing this in their tool when I get the chance, after porting the cubeIDE code over. Not on the top of my list so it may be awhile.

Pavel A.

A good debugger is much more important than editor and builder. You can easily find a free editor; good debugger is priceless.

Sign up

Login with SSO

Login to the community

Login with SSO