Monday, April 23rd 2018, 1:26pm UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

markuskrug

Beginner

Date of registration: Oct 19th 2016

Posts: 17

1

Thursday, January 11th 2018, 1:30pm

[SOLVED] 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
Markus

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 947

2

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,
Nino
SEGGER - Nino has attached the following file:
  • same70_printf.zip (947.46 kB - 35 times downloaded - Last download: Apr 21st 2018, 2:36am)
Please read the forum rules before posting: Forum Rules

Keep in mind, this is not a support forum. Its main purposes is user to user interaction.
Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
Should you be entitled to support contact us per e-mail.
The following contact form can be used for this: https://www.segger.com/about-us/contact-us/


markuskrug

Beginner

Date of registration: Oct 19th 2016

Posts: 17

3

Wednesday, January 17th 2018, 5:02pm

Solved?

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:
main->printf->vsnprintf->__vfprintf/__vfprintf_int_nwp
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
Markus

SEGGER - Nino

Super Moderator

Date of registration: Jan 2nd 2017

Posts: 947

4

Thursday, January 18th 2018, 2:25pm

Hello Markus,

Great to hear that you are up and running again.
Thank you for sharing your findings.
It is possible that TCM RAM needs some extra init steps or consideration in the IDE when using printf.
We do not have any "secret" extra knowledge about the SAME70 series that would not be described in the devices manual.
As a tool provider we guarantee that internal RAM and Flash that we support will be taken care of by J-Link.
Any extra memory areas that require user configuration will usually function with J-Link but we do not offer assistance in such setups.
Please contact the MCU vendor about such assistance or extra information.

We will consider this case as closed now.

Best regards,
Nino
Please read the forum rules before posting: Forum Rules

Keep in mind, this is not a support forum. Its main purposes is user to user interaction.
Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
Should you be entitled to support contact us per e-mail.
The following contact form can be used for this: https://www.segger.com/about-us/contact-us/