• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 25 subscribers
  • Views 116 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290540
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Moving from SES dev environment to Make/GCC - Hardfaulting

user103507

Hi,

We are trying to move from segger studio build environment to GCC/Make starting from the Example Makefile and adding source files and includes. The project consists of a softdevice (s132), bootloader and application.

The issue is that we enter the hardfault handler in the bootloader. See the backtrace log below.

What is also quite weird is that after resetting the device we now get a hardfault at __libc_init_array, i.e. way before main() is called upon. If an --eraseall is performed and re-flashing the device we get the error above again.

I have no clue as to what causes this, the SDK_CONFIG is unchanged. Pretty much the same flags is used except for the SES flags and the startup file is changed to the gcc variant from the ses one.

Thanks for the help in advance!

Parents
  • 0

    Hi,

    This does odd.. Can you describe more about your bootloader? The SDK example bootloader (which can be used more or less as is) comes with Makfiles, so unless you have done a lot of changes it might be easier and faster to go back to a working SDK example bootloader and modify it / adding back your changes.

  • 0 in reply to user7377

    The bootloader is built upon the secure_bootloader example makefile same as the segger project. I did manage to get past the bootloader and into the application after flashing the device with settings.hex file generated from nrfutil. However i suspected there is something weird going on with the softdevice and uart as well.

    In our main function in the application we initialize UART (in the same way from the peripheral example) and it returns success but immidietly after that we recieve and APP_UART_COMMUNICATION_ERROR which is odd because I have made sure we don't have anything communication over UART. This will also lead to a crash to some uknown address and if the device is reset it will no longer enter the application and what you see below is backtrace

    0x000782de in ?? ()
    (gdb) bt
    #0 0x000782de in ?? ()
    #1 <signal Handler is called>
    #2 0x00000000 in ?? ()
    #3 0x0007da24 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?)

  • 0 in reply to user103507

    This seems really odd... Regarding UART, that should not be related to the bootloader at all. If you are not using UART transport in the bootloader, it is never touched by the bootloader, and should be in the same state. It is also puzzling that you see different behavior even after reset when something has happened. Thirdly, it is interesting that you always get the same error indication stack corruption, and you get the same in different situations from both the bootloader and application.

    What differences are there between your Makefiles (including the inherited ones) compared to the SDK Makefiles? And linker scripts? And which GCC version are you using (we state in the release notes which one we tested the release with).

    I really don't have any specific advice at this point, but I would ask again if you considered going back to our example Makefiles, testing and adding your changes gradually? Perhaps then you will quickly see what changes seems related to this issue?

Reply
  • 0 in reply to user103507

    This seems really odd... Regarding UART, that should not be related to the bootloader at all. If you are not using UART transport in the bootloader, it is never touched by the bootloader, and should be in the same state. It is also puzzling that you see different behavior even after reset when something has happened. Thirdly, it is interesting that you always get the same error indication stack corruption, and you get the same in different situations from both the bootloader and application.

    What differences are there between your Makefiles (including the inherited ones) compared to the SDK Makefiles? And linker scripts? And which GCC version are you using (we state in the release notes which one we tested the release with).

    I really don't have any specific advice at this point, but I would ask again if you considered going back to our example Makefiles, testing and adding your changes gradually? Perhaps then you will quickly see what changes seems related to this issue?

Children
Related
Terms of service