Failing to run on nRF52805

[Daniel Dakhno]

I compiled some legacy code (once written for the nRF52832), trying to adapt it for the nRF52805.

I have already done the following:

• defining -DNRF52805_XXAA
• defining -mfloat-abi=soft
• defining-DFLOAT_ABI_SOFT
• adapted the linker script to this:

  FLASH (rx) : ORIGIN = 0x1C000, LENGTH = 0x30000 - 0x1C000
  RAM (rwx) :  ORIGIN = 0x20002730, LENGTH = 0x6000 - 0x2730

My SD is configured like this:

#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
#define NRF_SDH_BLE_VS_UUID_COUNT 3
#define NRF_SDH_BLE_GAP_EVENT_LENGTH 320
#define NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE 1408

Now I would be thankful to have these questions answered:

1. Why does the SD113 require so much RAM (0x2730 compared to 0x1198 as in the docs)? I am using 3 VS UUIDs, but does that really hog so much memory?
2. Do I need to compile gcc_startup_nrf52805.S or gcc_startup_nrf52.S? Same for system_nrf52805.c? When do I use which?
3. The code will simply not boot on my nRF52805. Is there any setting I am missing?

Thanks!

[tesc]

Hi,

Why does the SD113 require so much RAM (0x2730 compared to 0x1198 as in the docs)? I am using 3 VS UUIDs, but does that really hog so much memory?

Minimum RAM requirement is 0x1198 bytes. Call stack usage comes on top, with maximum 0x700 bytes. In addition, depending on configuration, additional RAM requirements apply. Ref. S113 Release notes "SoftDevice properties" section for the given release (in this caes s113_nrf52_7.3.0.)

Do I need to compile gcc_startup_nrf52805.S or gcc_startup_nrf52.S? Same for system_nrf52805.c? When do I use which?

Setup, includes, etc. depend on toolchain (nRF5 SDK support multiple). However, switch between different SoCs typically involve changing RAM and Flash settings and a simple define change; the rest (which SoC specific files are involved in builds) is then typically handled by the MDK. For instance, for Keil, there should be a selection in project settings. You may have to also switch between hardware and software floating point.

The code will simply not boot on my nRF52805. Is there any setting I am missing?

If it still fails, please consult Developing for the nRF52805 with nRF5 SDK.

Worst case, it might be that the total memory requirements of your application is simply too large for what is available on the nRF52805.

Regards,
Terje

[Daniel Dakhno]

Hello,

thanks for the reply!

1. Is 0x2730 realistic? I see that the SD may require more than 0x1198, but 0x2730 seems extremely large. Is there some formula available for the calculation?

2. I am using nRF5 SDK 17.1. Should I include gcc_startup_nrf52805.S or gcc_startup_nrf52.S?

3. My linker script is written to top out at the physical limit of the chip (0x6000). The firmware should fail at compilation time if it needed to much RAM, right? Or can it really fail at runtime aswell?

Thanks again!

P.S.: Thinking about it again: Is the stack not filled up from the end of RAM backwards? And since the exact same binary runs on the nRF52832, should the stack not be sufficient?

[tesc]

Hi,

You are correct.

Then I see what you mean. With the same RAM settings the difference should not be large, no. There may be smaller differences e.g. due to floating point or other SoC differences, though.

I assume you have gone through Developing for the nRF52805 with nRF5 SDK in case there are any configurations still missed, and also that the RAM requirement of 0x2730 is the same for both devices?

Regards,
Terje

[Daniel Dakhno]

Hi,

I have performed all the steps listed in the article.

I have set all flags to soft float.

The exact same firmware file with the following linker script ran on the 32, but not the 05, without recompiling.

FLASH (rx) : ORIGIN = 0x1C000, LENGTH = 0x30000 - 0x1C000
RAM (rwx) :  ORIGIN = 0x20002730, LENGTH = 0x6000 - 0x2730

Thanks for your time on this!

[tesc]

Hi,

Right. What boards have you been using, and does it run in emulated mode on e.g. nRF52 DK with nRF52833, then with the DEVELOP_IN_NRF52832 flags? Those flags should be present when emulating on the nRF52832, but not when running natively on the nRF52805.

Regards,
Terje

[Daniel Dakhno]

Hi,

here are the CFLAGS I am using. These produce a binary that works on the 32, but not on the 05.

Any Idea what is missing / wrong?

-DS113
-DNRF52
-DNRF52805_XXAA
-DHARDWARE_PIN_COUNT=32
-DNRF_CRYPTO_ALLOCATOR=3
-DNRF_CRYPTO_BACKEND_OBERON_ENABLED=1
-DNRF_CRYPTO_BACKEND_NRF_HW_RNG_ENABLED=1
-DDEVELOP_IN_NRF52832
-DNRF_SD_BLE_API_VERSION=7
-DAPP_TIMER_TICKS_COMPAT\(time,prescaler\)=APP_TIMER_TICKS\(time\)
-DNRF_DFU_SETTINGS_COMPATIBILITY_MODE=1
-DCONFIG_NFCT_PINS_AS_GPIOS=1
-DMBEDTLS_MEMORY_BUFFER_ALLOC_C
-DMBEDTLS_PLATFORM_MEMORY
-DFAMILY=52
-mcpu=cortex-m4
-mfloat-abi=soft
-DFLOAT_ABI_SOFT
-DSOFTDEVICE_PRESENT
-DBLE_STACK_SUPPORT_REQD
-DSWI_DISABLE0
-mthumb
-mabi=aapcs
-Wall
-Werror
-O2
-g3
-ffunction-sections
-fdata-sections
-fno-strict-aliasing
-fno-builtin
--short-enums
-DNRF_DFU_SETTINGS_VERSION=1
-DUSE_DFU
-DBUTTON_PIN=BUTTON_0
-DFIRMWARE_VERSION="0.9.0"
-DCLOCK_CONFIG_LF_SRC=0
-DNRF_SDH_CLOCK_LF_SRC=0
-DNRF_SDH_CLOCK_LF_RC_CTIV=16
-DNRF_SDH_CLOCK_LF_RC_TEMP_CTIV=2
-DNRF_SDH_CLOCK_LF_ACCURACY=1
-DDEBUG=1

I am not using a bootloader, but the DFU flags shouldn't do any harm, right?

Thanks for your help so far!

[Daniel Dakhno]

Heyo,

I found the issue.

I attached a debugger in the midst of the Hardfault Handler.

Then, using the stacktrace, I figured out that I was attempting to read out of bounds of the flash.

This happened in a piece of code I completely forgot about: github.com/.../storage.nrf52.c

My bad, thanks for standing by my side through this!