GNU Arm Embedded Toolchain

printf floating pt with STM32F103 giving crazy output

Asked by Donald Haselwood

On a custom board with a STM32F103VCT6 (Cortex-m3) printf is giving zeros or a very long nonsense number, e.g. the following code produces 0.00, -0.00, or a varying length (up to around 100) of numbers ending in .00, when all the time the integer printf produces a value of about 140 (the integer printf seems to work OK).
...
double therm[NUMBERADCCHANNELS_TEN];
...
printf("%10.2f", therm[1]);

'Makefile' includes the following--
...
CFLAGS = -std=gnu99 -g -Os -Wall -Wextra
CFLAGS += -mlittle-endian -mthumb -mthumb-interwork -nostartfiles
CFLAGS += -fno-common -mcpu=cortex-m3 -Wstrict-prototypes
override FLOAT_TYPE = soft
CFLAGS += -msoft-float
...
LGCC = /opt/launchpad/gcc-arm-none-eabi-4_9-2015q2/lib/gcc/arm-none-eabi/4.9.3/armv7-m
LOTHER = /opt/launchpad/gcc-arm-none-eabi-4_9-2015q2/arm-none-eabi/lib/armv7-m
...

Using the same version of launchpad on a DiscoveryF4 with hard floating pt the printf works fine with floating pt, however the program, Makefile, startup code, though similar, are not identical.

(This is all bare metal C. For the F103 I've been using "tiny printf" which only does integers. Floating pt printf would be handy for the latest project, but "manually coding" a floating pt output seems silly when the launchpad printf should do the job.)

At this point I'm suspicious that it might have to do with startup and initialization, but I don't know what it might be and what to try. Any suggestions as to what-and-where to look would be appreciated.

Question information

Language:
English Edit question
Status:
Expired
For:
GNU Arm Embedded Toolchain Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Thomas Preud'homme (thomas-preudhomme) said : 		#1

Hi Donald,

We were not able to reproduce this on our side. Could you give us a full testcase for us to compile? Ideally this should be a preprocessed file (-save-temps while compiling the unprocessed C file will create a preprocessed .i file).

Best regards.

Revision history for this message
Donald Haselwood (dhaselwood) said : 		#2

Thomas,

Thanks for the response. I'll see if I can strip the current program
down to a simple test case. It may take some time as I have some
out-of-town days coming up.

Don

On Fri, 2015-07-31 at 03:46 +0000, Thomas Preud'homme wrote:
> Your question #269683 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/269683
>
> Status: Open => Needs information
>
> Thomas Preud'homme requested more information:
> Hi Donald,
>
> We were not able to reproduce this on our side. Could you give us a full
> testcase for us to compile? Ideally this should be a preprocessed file
> (-save-temps while compiling the unprocessed C file will create a
> preprocessed .i file).
>
> Best regards.
>

Revision history for this message
Donald Haselwood (dhaselwood) said : 		#3

Thomas,

I put some code that demonstrates the problem I am having on a github
repo--

https://github.com/deh/launchpad_fp_test

I included the .i files as well as the compiled code. I tried a clone
of the repo and it compiled OK, but that was on my machine and there is
a reasonable chance I have something local on my machine (Ubuntu 12.04
LTS) that would stop it on someone else's machine.

I included 'serialout.txt' file with the serial port output.

If some of the organization looks a little strange is likely because
directories, routines, and libraries were lifted, stripped, and hacked
to reduced the amount of code. Some of the code goes back nearly 5 yrs.
We were using CodeSourcery at that time.

At the moment my sense is that the problem is with the compiler
flags/switches; the .ld file; or maybe even something having to do with
'newlibsupport' such as 'malloc', but I haven't found any clues. (And
of course the most difficult problems are sometimes extremely simple
mistakes that are constantly overlooked...)

Don

On Fri, 2015-07-31 at 03:46 +0000, Thomas Preud'homme wrote:

> Your question #269683 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/269683
>
> Status: Open => Needs information
>
> Thomas Preud'homme requested more information:
> Hi Donald,
>
> We were not able to reproduce this on our side. Could you give us a full
> testcase for us to compile? Ideally this should be a preprocessed file
> (-save-temps while compiling the unprocessed C file will create a
> preprocessed .i file).
>
> Best regards.
>

Revision history for this message
Launchpad Janitor (janitor) said : 		#4

This question was expired because it remained in the 'Open' state without activity for the last 15 days.