first post, perplexed by printf()

first post, perplexed by printf()

[Dave McGuire]

  Hi folks.  New list member here; I'm sure I'll see some familiar names.

  I've been using newlib for several years on a few different ARM7
platforms, primarily the NXP LPC family, with great results. (thanks!)
I'm just getting stuff running on my first CortexM3-based system now,
and printf() has me stymied.

  I'm hoping this is a simple thing that someone else has run into.  I
don't have any reasonable way to get a debugger running on my board just
yet, so I figured I'd just ask here to see if someone pipes up and says
"Oh!  It's just <xyz>."

  If I do printf("%d\n", 1); everything works fine.  If I do
printf("%d\n", 10);, my processor hangs.  (again with no debugging
support just yet, I don't know where)  In other words, as soon as I try
to format an integer with more than one digit, it hangs.  I can add
characters to the format string, and it works.  I've given it ever more
stack, no change. (I'm aware of printf()'s appetite for memory)

  I'm using the 2.1.0 snapshot of newlib, standard multilib config, with
GCC v4.9.1 on an Energy Micro/SiLabs EFM32GG-series processor.  Same
toolchain and newlib build as I have working on lots of designs with
non-Cortex ARM7 processors.

  Before I dig any deeper, does this ring a bell for anyone?

                Thanks,
                -Dave

-- 
Dave McGuire, AK4HZ/3
New Kensington, PA

Re: first post, perplexed by printf()

[Freddie Chopin]

On 10/03/2014 05:42 AM, Dave McGuire wrote:
> If I do printf("%d\n", 1); everything works fine.  If I do
> printf("%d\n", 10);, my processor hangs.  (again with no debugging
> support just yet, I don't know where)  In other words, as soon as I try
> to format an integer with more than one digit, it hangs.  I can add
> characters to the format string, and it works.  I've given it ever more
> stack, no change. (I'm aware of printf()'s appetite for memory)

Before digging any further set stack to 4kB (or 2kB at least). Second 
thing - make sure your stack is 8-byte aligned (this shouldn't be a 
problem for printf()ing ints, but its better to be safe).

You could also try one of my example ARM projects, take the one for 
Cortex-M3 (like the one for STM32F4) and just do these two things:
- disable any hardware-specific calls in main() - setting the PLL, 
GPIOs, ...,
- adjust the sizes and addresses of memories in the linker script to 
match your chip (you can also increase the stack size).

Then download the "syscalls" package, drop the source file into the main 
folder of the example and at this point printf() MUST work. To make it 
actually print anything, you'd also need to add your "retargetting" code...

Did you build the toolchain yourself or are you using some precompiled 
one? Have you tried your code with the "official" one - 
https://launchpad.net/gcc-arm-embedded or maybe with my own compilation 
- bleeding-edge-toolchain - http://sourceforge.net/projects/bleeding-edge/

Regards,
FCh

Re: first post, perplexed by printf()

[Dave McGuire]

  Hi Freddie, thank you for your prompt reply.  I apologize for my
not-so-prompt reply to your reply. ;)  I'm digging into this a bit
today; see inline replies below.

On 10/03/2014 03:13 AM, Freddie Chopin wrote:
>> If I do printf("%d\n", 1); everything works fine.  If I do
>> printf("%d\n", 10);, my processor hangs.  (again with no debugging
>> support just yet, I don't know where)  In other words, as soon as I try
>> to format an integer with more than one digit, it hangs.  I can add
>> characters to the format string, and it works.  I've given it ever more
>> stack, no change. (I'm aware of printf()'s appetite for memory)
> 
> Before digging any further set stack to 4kB (or 2kB at least). Second
> thing - make sure your stack is 8-byte aligned (this shouldn't be a
> problem for printf()ing ints, but its better to be safe).

  I had tried it up to 16KB; no change.  I believe the alignment is ok,
as I just start the stack at the top of RAM.

> You could also try one of my example ARM projects, take the one for
> Cortex-M3 (like the one for STM32F4) and just do these two things:
> - disable any hardware-specific calls in main() - setting the PLL,
> GPIOs, ...,
> - adjust the sizes and addresses of memories in the linker script to
> match your chip (you can also increase the stack size).
> 
> Then download the "syscalls" package, drop the source file into the main
> folder of the example and at this point printf() MUST work. To make it
> actually print anything, you'd also need to add your "retargetting" code...

  Ok, I will hack on this a bit today and see how far I get.  The linker
script and startup code I'm using are the ones distributed by SiLabs for
this family of processors.  At first glance, your linker script and
startup code are very different from those.

> Did you build the toolchain yourself or are you using some precompiled
> one? Have you tried your code with the "official" one -
> https://launchpad.net/gcc-arm-embedded or maybe with my own compilation
> - bleeding-edge-toolchain - http://sourceforge.net/projects/bleeding-edge/

  I'm using a self-built toolchain.  A long time ago I got tired of
fighting with pre-built toolchains that sucked in one way or another, so
I wrote my own build script that (to me) does things more sanely and
gives me a high degree of target-to-target consistency.  I've been using
it since about 2008 with good results and haven't really looked at any
others since then.  The "official" one did not exist at that time. (or
at least I never found it)  I will give yours a look.

                    Thanks,
                    -Dave

-- 
Dave McGuire, AK4HZ/3
New Kensington, PA

Re: first post, perplexed by printf()

[Federico Terraneo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/10/2014 22:43, Dave McGuire wrote:
> 
> Ok, I will hack on this a bit today and see how far I get.  The
> linker script and startup code I'm using are the ones distributed
> by SiLabs for this family of processors.  At first glance, your
> linker script and startup code are very different from those.
> 

Hi,
This is just a guess, as I have not seen the SiLabs linker script, but
have you tried if malloc works on your platform, such as trying to
allocate some blocks, writing into them and seeing if it makes the
system crash? I've seen some linker script in the past, provided by
chip manufacturers, which fail to set up a working heap, and printf
calls malloc internally.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iF4EAREIAAYFAlQyUx8ACgkQbTKLH9en/LsZ9gD/Ri+4qk3Ne20e/RSsfOQ+DNeO
uycjcGKNHMZKYTyyV/sA/1EtrO02I+z+LicJT/V++fso+3wFtVSl5iCvRbZlA/3A
=3XfA
-----END PGP SIGNATURE-----

Re: first post, perplexed by printf()

[Dave McGuire]

On 10/06/2014 04:30 AM, Federico Terraneo wrote:
>> Ok, I will hack on this a bit today and see how far I get.  The
>> linker script and startup code I'm using are the ones distributed
>> by SiLabs for this family of processors.  At first glance, your
>> linker script and startup code are very different from those.
> 
> This is just a guess, as I have not seen the SiLabs linker script, but
> have you tried if malloc works on your platform, such as trying to
> allocate some blocks, writing into them and seeing if it makes the
> system crash? I've seen some linker script in the past, provided by
> chip manufacturers, which fail to set up a working heap, and printf
> calls malloc internally.

  Hi!  I got sidetracked by other work last night and today, and didn't
get very far in my efforts.  I'll take another stab at it tomorrow.

  But as far as malloc(), that's working fine, and I just verified it
again (to make sure the compiler wasn't optimizing it out, etc).  I'm
able to malloc() a 4K chunk of memory and initialize it in a loop.

                  -Dave

-- 
Dave McGuire, AK4HZ/3
New Kensington, PA

Re: first post, perplexed by printf()

[Jonathan Roelofs]

On 10/3/14 1:13 AM, Freddie Chopin wrote:
> On 10/03/2014 05:42 AM, Dave McGuire wrote:
>> If I do printf("%d\n", 1); everything works fine.  If I do
>> printf("%d\n", 10);, my processor hangs.  (again with no debugging
Pointed question: where did you get your implementation of __aeabi_divmod?
>> support just yet, I don't know where)  In other words, as soon as I try
QEMU might be another option to get a debugger hooked up to inspect the thing at
runtime.

Cheers,
Jon

>> to format an integer with more than one digit, it hangs.  I can add
>> characters to the format string, and it works.  I've given it ever more
>> stack, no change. (I'm aware of printf()'s appetite for memory)

-- 
Jon Roelofs
jonathan@codesourcery.com
CodeSourcery / Mentor Embedded

Re: first post, perplexed by printf()

[Dave McGuire]

On 10/07/2014 09:07 AM, Jonathan Roelofs wrote:
>>> If I do printf("%d\n", 1); everything works fine.  If I do
>>> printf("%d\n", 10);, my processor hangs.  (again with no debugging
>
> Pointed question: where did you get your implementation of __aeabi_divmod?

  Well I certainly didn't write it. ;)  Isn't that in libgcc?

               -Dave

-- 
Dave McGuire, AK4HZ/3
New Kensington, PA

Re: first post, perplexed by printf()

[Jonathan Roelofs]

On 10/8/14 10:36 AM, Dave McGuire wrote:
> On 10/07/2014 09:07 AM, Jonathan Roelofs wrote:
>>>> If I do printf("%d\n", 1); everything works fine.  If I do
>>>> printf("%d\n", 10);, my processor hangs.  (again with no debugging
>>
>> Pointed question: where did you get your implementation of __aeabi_divmod?
> 
>   Well I certainly didn't write it. ;)  Isn't that in libgcc?
Yeah, that comes from libgcc. The pointed question was aimed at whether you were
using the one from llvm's compiler_rt, which had a bug which has subsequently
been fixed, that manifested itself in a similar manner. But since you're not
using that, it's probably not the same problem.


When your processor hangs, can you tell if it's hitting an interrupt, and if so
which one?
> 
>                -Dave
> 

-- 
Jon Roelofs
jonathan@codesourcery.com
CodeSourcery / Mentor Embedded

Re: first post, perplexed by printf()

[Dave McGuire]

On 10/08/2014 02:05 PM, Jonathan Roelofs wrote:
>>>>> If I do printf("%d\n", 1); everything works fine.  If I do
>>>>> printf("%d\n", 10);, my processor hangs.  (again with no debugging
>>>
>>> Pointed question: where did you get your implementation of __aeabi_divmod?
>>
>>   Well I certainly didn't write it. ;)  Isn't that in libgcc?
> Yeah, that comes from libgcc. The pointed question was aimed at whether you were
> using the one from llvm's compiler_rt, which had a bug which has subsequently
> been fixed, that manifested itself in a similar manner. But since you're not
> using that, it's probably not the same problem.

  Nope, not that.  Thanks for the thought, though!

> When your processor hangs, can you tell if it's hitting an interrupt, and if so
> which one?

  I haven't looked that far yet, but on a lark I just tried the
"official" gcc-arm-embedded toolchain, and my (unmodified) code runs,
with my linker script and startup code...so there's something wrong with
my toolchain.

  "Dang these guys and their broken home-built toolchains!" ;)

  (It has worked wonderfully for many years on dozens of projects, but
this is the first time I've targeted a thumb-only processor, so it's
gotta have something to do with that.)

  So that "official" toolchain looks to be Cortex-only, oddly, which is
a problem for me.

  I'll go digging through their build scripts to see if I can figure out
what's going on.

                  -Dave

-- 
Dave McGuire, AK4HZ/3
New Kensington, PA

Re: first post, perplexed by printf()

[Jeff Johnston]

Some ideas:

A failure that occurs by making a slight code modification can sometimes indicate an invalid storage access
has occurred.  Assuming that your code is more complex than just a single printf, have you tried running your code 
through Valgrind to see if you perhaps have any such items as uninitialized pointer reference, array bounds
issues, or referencing freed storage?  Perhaps something is relying on malloc'd heap storage being clear.

Can you verify that the .bss area is cleared properly for your tool-chain at start-up?

-- Jeff J.

----- Original Message -----
> From: "Dave McGuire" <mcguire@neurotica.com>
> To: newlib@sourceware.org
> Sent: Wednesday, October 8, 2014 3:12:01 PM
> Subject: Re: first post, perplexed by printf()
> 
> On 10/08/2014 02:05 PM, Jonathan Roelofs wrote:
> >>>>> If I do printf("%d\n", 1); everything works fine.  If I do
> >>>>> printf("%d\n", 10);, my processor hangs.  (again with no debugging
> >>>
> >>> Pointed question: where did you get your implementation of
> >>> __aeabi_divmod?
> >>
> >>   Well I certainly didn't write it. ;)  Isn't that in libgcc?
> > Yeah, that comes from libgcc. The pointed question was aimed at whether you
> > were
> > using the one from llvm's compiler_rt, which had a bug which has
> > subsequently
> > been fixed, that manifested itself in a similar manner. But since you're
> > not
> > using that, it's probably not the same problem.
> 
>   Nope, not that.  Thanks for the thought, though!
> 
> > When your processor hangs, can you tell if it's hitting an interrupt, and
> > if so
> > which one?
> 
>   I haven't looked that far yet, but on a lark I just tried the
> "official" gcc-arm-embedded toolchain, and my (unmodified) code runs,
> with my linker script and startup code...so there's something wrong with
> my toolchain.
> 
>   "Dang these guys and their broken home-built toolchains!" ;)
> 
>   (It has worked wonderfully for many years on dozens of projects, but
> this is the first time I've targeted a thumb-only processor, so it's
> gotta have something to do with that.)
> 
>   So that "official" toolchain looks to be Cortex-only, oddly, which is
> a problem for me.
> 
>   I'll go digging through their build scripts to see if I can figure out
> what's going on.
> 
>                   -Dave
> 
> --
> Dave McGuire, AK4HZ/3
> New Kensington, PA
> 

Re: Re: first post, perplexed by printf()

[David Fernandez]

Without the silly disclaimer this time... (and plain text)

On 08/10/14 20:12, Dave McGuire wrote:
>    (It has worked wonderfully for many years on dozens of projects, but
> this is the first time I've targeted a thumb-only processor, so it's
> gotta have something to do with that.)
Just an idea:

I remember that, when I first built thumb-only toolchains, I run into 
the problem of the toolchain building the library for arm32, rather than 
thumb.

As you are building a multi-lib toolchain, something like that might be 
happening for libgcc?

May be worth checking.