Defect report: sprintf() with floats just prints 0x00 with no error.

[Anonymous]

Defect report: sprintf() with floats just prints 0x00 with no error.

   

This error existed earlier with the nano lib, and the fix was to either:

   

a. Disable newlib-nano in the linker, or

   

b. Enable newlib-nano Float Formatting, or

   

c. Add "-u _printf_float" to the linker command line

   

Now, none of these fixes does anything anymore.

[ETRO_SSN583]

Prior to Creator 3.1 the stack and heap sizes were fixed by part group

   

and large. That changed with 3.1 and so you might want to increase them.

   

From 3.1 release notes -

       

Default Stack and Heap Sizes
The default stack and heap sizes for new projects have been adjusted to more closely match real-world
requirements. When new projects are created, the stack size is set to be a fraction of the total SRAM in
the target device. The heap is set to a small value - 128 bytes - for all devices. You can, of course, modify
these settings in the Design-Wide Resources System Editor. For example, if you are not using any heap
based memory allocation the heap can safely be set to 0 bytes.
Note that some example projects and application notes were originally created on older versions of PSoC
Creator and use the larger default sizes. These projects will continue to build and run perfectly because
they have sufficient memory allocated. However, if you attempt to reproduce the example yourself in your
own project you may need to adjust the stack and heap. However, the example documentation will not tell
you to do that because the original project did not require the settings to be changed.

       

http://www.cypress.com/forum/psoc-5-device-programming/problem-printing-float

       

Regards, Dana.
 

[Anonymous]

Unclear how stack and heap size addresses the issue.

[Anonymous]

Quoted from another site:

       

When a floating-point format specifier is used with sprintf, one of sprintf's subroutines calls malloc. If malloc returns NULL, the subroutine attempts to write to address 0x00000004 at _dtoa_r+0x1C (looking through the source, it looks like multiple malloc calls are affected; the issue was discovered with newlib-nano but may also affect newlib). On the target processor, this memory is read-only, so the CPU jumps to the exception vector. Dereferencing invalid pointers can lead to undefined (or at least unexpected) behavior. If malloc fails, sprintf should return a value indicating that an error occurred.

       

Micro programming ain't like windows or linux. We don't live in an environment, we are the environment.

       

Ed

[Bob_Marlowe]

OK, converting float to string:

   

Upgrade to Creator 3.3 (That is the latest version)

   

In your project set heap to 0x0200 + your own amount for malloc()s

   

set "Use newlib-nano" to True

   

set "Use newlib-nano float formatting" to true

   

use sprintf() with a buffer large enough to hold the resulting string and the terminating \0 character.

       

- that's it

       

Bob