[SOLVED] printf leads to hardfault even in 'default' application

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [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
  • 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
    Files
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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
  • 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.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.