This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: newlib-1.18.0 arm-none-eabi and sniprintf %d bug
- From: Simon Berg <ksb at fluffware dot se>
- To: Stuart Longland <redhatter at gentoo dot org>
- Cc: newlib at sourceware dot org
- Date: Sat, 08 Jan 2011 15:09:38 +0100
- Subject: Re: newlib-1.18.0 arm-none-eabi and sniprintf %d bug
- References: <4D265DAC.9040002@gentoo.org>
On Fri, 2011-01-07 at 10:26 +1000, Stuart Longland wrote:
> Hi all,
>
> I'm doing some development on an STM32F103VE microcontroller. I've
> compiled a toolchain myself (using crossdev) for the arm-none-eabi CHOST
> using binutils-2.21, gcc-4.5.2 and newlib-1.18.0. Everything seems to
> work fine, except sniprintf (and snprintf).
Which port are you using? The one in cpu/arm/stm32f103 ?
That one uses it's own implementation of printf (and snprintf) instead
of the one provided by newlib because of code size.
All formatting is done using cpu/arm/common/dbg-io/strformat.c
sniprintf does not have an alternative implementation so your probably
picking up the one from newlib.
>
> sniprintf is fine with strings (%s). It works fine with hexadecimal
> digits (%x), however I'm finding I'm getting hard-locks with decimal
> digits (%d). The MCU enters the function, and seemingly never exits.
And snprintf behaves the same?
>
> Unfortunately I do not have a JTAG hooked up, and I'm unsure where to
> begin debugging newlib as being new to the innards of the C library, I'm
> finding it difficult to trace the execution flow.
>
> Anyone have any suggestions where to begin?
>
simon