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
Hi Simon,
On 01/09/11 00:09, Simon Berg wrote:
> 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.
Had no ideas there were CPU-specific ports, I just picked arm-none-eabi
and though that'd be the right target. How does one select that port?
> 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?
Yes, snprintf also hard-locks the thing (as well as being bigger due to
softfloat).
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL) .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer '.'` :
. . . . . . . . . . . . . . . . . . . . . . .'.'
http://dev.gentoo.org/~redhatter :.'
I haven't lost my mind...
...it's backed up on a tape somewhere.