STM32F1 and printing floating point values

The Nodate printf routines do not appear to work correctly when printing floating point values with a NUCLEO-F103RB board. The resulting values frequently appear as "0.000". This behavior seems to be limited to STM32F1 - correct operation is seen with F0, F4, and F7 series. The following is the test code used:

// printf STM32F1 test for Nodate's STM32 framework.
include <usart.h>
#include <io.h>
#include "printf.h"

void uartCallback(char ch) {
	// Copy character into send buffer.
	USART::sendUart(USART_2, ch);
}

int main () {
	SystemCoreClockUpdate();
	// nucleo-f103rb
	USART::startUart(USART_2, GPIO_PORT_A, 2, 0, GPIO_PORT_A, 3, 0, 9600, uartCallback);
	// Set up stdout.
	// nucleo-f103rb
	IO::setStdOutTarget(USART_2);
	USART_devices my_usart = USART_2;
	volatile int t1 = 4;
	printf("Int test: %i.\n", t1);
	printf("Int to Float test: %f.\n", t1);
	volatile float t = 4.23;
	printf("Float test: %f.\n", t);
	while(1) {
		//
	}
	
	return 0;
}

That's very curious behaviour, yeah... Nodate uses the small printf implementation from mpaland: https://github.com/mpaland/printf/

Had a quick look at outstanding issues for that project to see whether anyone else stumbled over such an issue, but apparently not. Looking in the source of printf.c there's nothing that jumps out at me as not working on STM32F1.

I assume this issue still exists for you?

It still exists for me. I looked over the printf implementation and nothing jumped out at me. My day job is pretty hectic at the moment, but next week I should have some time to try and isolate the issue. I’ll spin up another VM and see if my os/compiler installations are the problem. I will also check the compiler options I’m using and see if anything might be causing side effects.

Alan

On Oct 11, 2021, at 8:04 AM, Maya Posch @.***> wrote:

That's very curious behaviour, yeah... Nodate uses the small printf implementation from mpaland: https://github.com/mpaland/printf/ https://github.com/mpaland/printf/ Had a quick look at outstanding issues for that project to see whether anyone else stumbled over such an issue, but apparently not. Looking in the source of printf.c there's nothing that jumps out at me as not working on STM32F1.

I assume this issue still exists for you?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MayaPosch/Nodate/issues/18#issuecomment-939966964, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKI355UK4PB3FICYBXWZSDUGLHE3ANCNFSM5DZQKRJQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Still working on the problem. While the bug shows up on a NUCLEO-F103RB, the same code executes fine on a NUCLEO-F030R8. Digging a little deeper, the problem appears to occur when the _vsnprintf() routine calls _ftoa(). With the F0 mcu _ftoa() receives a “double” argument that looks correct. With the F1 mcu the “double” argument contains invalid data. It might be a data alignment issue - I’m still way down the learning curve in that area with a lot of learning to do.

Recently I loaded up the STM32CubeIDE and built a STM32F1 HAL project to use the mpaland printf routines. Everything worked successfully, which also points to possible issues with the compiler settings when using Nodate and an F1 mcu.

I will let you know what else I discover.

Alan

P.S. The issue also occurs when using the mpaland’s sprintf() routine. That test indicates the problem does not originate in the Nodate usart.cpp or io.cpp routines.

Begin forwarded message:

From: Alan Ford @.> Subject: Re: [MayaPosch/Nodate] STM32F1 and printing floating point values (#18) Date: October 14, 2021 at 4:28:29 PM EDT To: MayaPosch/Nodate @.>

It still exists for me. I looked over the printf implementation and nothing jumped out at me. My day job is pretty hectic at the moment, but next week I should have some time to try and isolate the issue. I’ll spin up another VM and see if my os/compiler installations are the problem. I will also check the compiler options I’m using and see if anything might be causing side effects.

Alan

On Oct 11, 2021, at 8:04 AM, Maya Posch @.*** @.***>> wrote:

That's very curious behaviour, yeah... Nodate uses the small printf implementation from mpaland: https://github.com/mpaland/printf/ https://github.com/mpaland/printf/ Had a quick look at outstanding issues for that project to see whether anyone else stumbled over such an issue, but apparently not. Looking in the source of printf.c there's nothing that jumps out at me as not working on STM32F1.

I assume this issue still exists for you?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MayaPosch/Nodate/issues/18#issuecomment-939966964, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKI355UK4PB3FICYBXWZSDUGLHE3ANCNFSM5DZQKRJQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Found a solution, but there may be side effects that are unknown at this time. The solution is to modify the linker script stm32f103xb.ld to change a line from: _estack = 0x20004FFF; /* end of RAM */ to _estack = 0x20005000; /* end of RAM */ This change would make the stack start on a 4-byte aligned location, consistent with the Nodate linker scripts used for other mcu's where this float problem does not occur. It would appear that a stack misaligned by 1 byte does not affect the use of data of size 4 bytes or less, but may cause problems with 8-byte doubles (used within the printf routines when formatting floats). It is unclear why the stack location was initialized to 0x20004FFF or what a change may affect. However, this stack design seems to occur in all of the STM32F1 linker scripts used in the Nodate library.