Skip to main content
X
XLei.1
Visitor II
April 2, 2021
Solved

STM32F407 failed with printf float

  • April 2, 2021
  • 2 replies
  • 1290 views

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?

    This topic has been closed for replies.
    Best answer by Walid ZRELLI

    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.

    2 replies

    W
    Walid ZRELLIAnswer
    Visitor II
    April 23, 2021

    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.

    O
    Ozone
    Explorer
    April 23, 2021

    > 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.

    Terms & ConditionsAccessibility statement