Re: first post, perplexed by printf()

[Dave McGuire <mcguire at neurotica dot com>]

  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