Moving from SES dev environment to Make/GCC - Hardfaulting

RE: Moving from SES dev environment to Make/GCC - Hardfaulting

user103507 — Thu, 16 Jun 2022 06:38:33 GMT

It seem the firmware and bootloader had several separated issues. I will create new more detailed issues instead.

RE: Moving from SES dev environment to Make/GCC - Hardfaulting

user7377 — Tue, 14 Jun 2022 11:26:49 GMT

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?

RE: Moving from SES dev environment to Make/GCC - Hardfaulting

user103507 — Tue, 14 Jun 2022 09:02:10 GMT

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?)

RE: Moving from SES dev environment to Make/GCC - Hardfaulting

user7377 — Mon, 13 Jun 2022 13:52:59 GMT

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.