Peer Manager and GCC

[Andrew]

I have attempted to migrate over a couple of nRF52 projects built around device manager to the new peer manager in SDK 11 that are built with eclipse and GCC. However, I am seeing the exact same behavior after each attempt. I am following the migration tutorial and everything to builds just fine but running in debug shows the application getting hung up at flash address 0x10 and disassembly shows the following:

          fs_config:
00000000:   beq.n   0xee
00000002:   movs    r1, r0
00000004:   movs    r0, r0
00000006:   movs    r0, r0
00000008:   movs    r0, r0
0000000a:   movs    r0, r0
0000000c:   movs    r3, r0
0000000e:   movs    r0, r0
00000010:           ; <UNDEFINED> instruction: 0xffffffff

The undefined instruction continues until address 0x1000, or one block of flash.

I also tried creating a new project around the example relay project that uses the peer manager but again, same result.

It seems that the fs_config is ignoring the flash start address in the linker script is wiping out the Softdevice flash for storage space (this is just a guess). I'm not sure how to fix this quickly or correctly.

[Richard von Lehe]

I have found that the gcc linker script used to place fs_config is not set up properly. I assume you're using a softdevice. What I've found is that the SECTION defined in the projects' linker script (e.g. ble_app_hrs_rscs_relay/pca10036/s132/armgcc) creates a section located at 0x0, which conflicts with the softdevice. In fact, I am wondering how you put this image into flash. If I try to do it using nRFGo Studio, it fails saying that part of your application is overflowing into the softdevice region.

[Andrew]

Making a debug configuration within Eclipse with the GDB SEGGER J-Link Debugging does not keep the fs_config from writing into the softdevice. So while it does flash the application, it kills the softdevice too.

[Richard von Lehe]

I've brought this up, but it hasn't been fixed yet. The first thing that needs to happen is to consolidate to only one SECTIONS definition between the project linker script and the common linker script (components/toolchain/gcc/nrf5x_common.ld. I've read that gcc/ld don't handle multiple SECTION definition. I did that and it avoided placing those 16 bytes at address 0x0, but it still didn't do the job right. If you look at the map file generated by IAR (not sure you have that available), you will see that fs_config gets placed in RAM and it's initial value gets copied from the .text section in flash. This isn't happening in the gcc version, so you'll see the fs_init call go haywire and eventually you'll hit an assert and restart ... over and over.

[Håkon Alseth]

Hi,

EDIT : This shall be fixed from nRF5_SDK_11.0.0_89a8197 and upwards

Fix for nRF5_SDK_11 alpha:

Had to re-order our common linker file, and for now; everything is included into one .ld file, due to ordering of the .data/.fs_data/.bss sections for initialization.

ble_app_hrs_rscs_relay_gcc_nrf52.ld

sector_vars.h

Best regards, Håkon

[Andrew]

Håkon,

Thank you for the reply. This fixes the Softdevice getting wiped out but I am still experiencing an issue during fs_init(). When setting the num_left variable with FS_SECTION_VARS_COUNT, it always returns 0. So when entering the do / while(--num_left > 0), it decrements the num_left and rolls over. I attempted to fix this by changing num_left from a uint32_t to an int32_t. This got me out of the do while loop, however it still looks like the wrong address is being assigned to p_config during FS_SECTION_VARS_GET().

If I allow the program to continue out of the do/while loop I run back into trouble when it moves on to static fds_init_opts_t pages_init(). Since the address is incorrect, it comes back as FDS_PAGE_UNDEFINED and when checked with page_is_empty(), it is looking at a page that is not empty and falls out of the switch statement.