cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F407 failed with printf float

XLei.1
Associate II

Hello,

I'm trying to setup the system based on SMT32F407 with ThreadX, and enable the print float option for logging feature. Everything works fine!

But when we started stability test, thousands of logs are composed with vsnprintf, but it finally fails in some call, like below shown:

0693W000008yZcHQAU.pngI tried to use "-mfloat-abi=soft" or "softtp" instead of "-mfloat-abi=hard", but no improvement at all. And I tried to find the answer from website, but no lucks for this issue.

Could anyone give me the opinion to resolve this issue?

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @Community member​ ,

Welcome to our Community :)

First , are the logs displayed first and then the code hangs, or does it display some logs and then it crashes?

In case some logs are displayed, we recommend that you perform a stack analysis or activate stack overflow detection in your RTOS in order to rule out a stack issue. please refer to this reference which may help you

Moreover, are you sure that the destination buffer for vsprintf has the adequate size?

Otherwise, the method that the logs are displayed/exported with might also cause an issue. For example, if they are output to a UART with speed 9600 baud 8-bit no parity, transferring 1000 bytes will take a little more than 1 second.

If the sending is done using a blocking API or without an API, some instability of the system can be expected. So, using trace (ETM) would be beneficial in this case.

I hope this help you,

Walid.

View solution in original post

2 REPLIES 2

Hello @Community member​ ,

Welcome to our Community :)

First , are the logs displayed first and then the code hangs, or does it display some logs and then it crashes?

In case some logs are displayed, we recommend that you perform a stack analysis or activate stack overflow detection in your RTOS in order to rule out a stack issue. please refer to this reference which may help you

Moreover, are you sure that the destination buffer for vsprintf has the adequate size?

Otherwise, the method that the logs are displayed/exported with might also cause an issue. For example, if they are output to a UART with speed 9600 baud 8-bit no parity, transferring 1000 bytes will take a little more than 1 second.

If the sending is done using a blocking API or without an API, some instability of the system can be expected. So, using trace (ETM) would be beneficial in this case.

I hope this help you,

Walid.

Ozone
Lead II

> But when we started stability test, thousands of logs are composed with vsnprintf, but it finally fails in some call, like below shown:

As stated, not a very close description of where and why it failed.

Floating point support for printf-like functions require a lot of code and stack space, this is why slim library versions leave it out.

I would avoid it it possible.

In my experience, default task stacksizes of RT OSes tend to be rather small by default. A point to check first.