Thursday, January 18th 2018, 1:21am UTC+1

You are not logged in.

  • Login
  • Register



Date of registration: Oct 19th 2016

Posts: 16


Thursday, January 11th 2018, 1:30pm

printf leads to hardfault even in 'default' application

Dear all,

I'm experience a strange behavior that might be related to my limited knowledge. I use SES for a ATMEL SAME70 device. If I setup a new project without changing any project parameter I observe that within the first printf("Hello World") the application stops with a hard fault. If I step into the printf I can see that it crash within the assembler function __vfprintf_int_nwp at the assembler command: pop.w {r4-r10, pc} at address 0x400DC2 (should be the same address for every standard memory map). To my knowledge the affected command tries to restore the CPU registers before jumping back to the calling function. The corresponding push command happens at the very beginning of the affected function.
I hope the problem is 'just' a lack of knowledge on my side and can be easily fixed. Any hint will be appreciated.

Best Regards


Super Moderator

Date of registration: Jan 2nd 2017

Posts: 551


Monday, January 15th 2018, 10:06am

Hello Markus,

*Note: This thread has been moved to SEGGER Embedded Studio related*

Thank you for your inquiry.
Such an issue is not known to us.
What Embedded Studio version were you using?
Did you use the CPU support package manager to generate an example project?

For reference I created the attached project with the CPU support package and the generic project wizard.
The project has been tested on a Smart SAME70 Xplained Ev. Kit with an external J-Link.

Could you test it out on your hardware and see if the printf is working as intended?
If it works, compare it to your project setup and see if there are any diffrences.

Best regards,
SEGGER - Nino has attached the following file:



Date of registration: Oct 19th 2016

Posts: 16


Yesterday, 5:02pm


Dear Nino,

thanks for taking care.
I tried you project with the same result that I had before. I run it on the Xplained E70 board. The board itself works fine with any other code - beside printf().

The program generates a hard fault after the following call stack:
in this function the restore of the stack seems to be the problem because the hard fault is generated at the assembler line: pop.w {r4-r10, pc} that is located at address 0x400DDE

After experience the same error I remembered that I was setting the GPNVM bits to use 128kByte TCM RAM and ROM. TCM is not used in your example project. So I erased those bits and suddenly the printf works. So fine for the moment although I do not fully understand why the TCM bits caused the problem. I guess it is related that TCM RAM consumes the normal RAM and the stack is located at the end of the normal RAM that is a different address if you use TCM RAM. However, that is just a guess that needs to be verified. It might be also related to the relative high stack demand of printf().

Again, thank you for providing a reference example.

Best Regards