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.

[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.

[Håkon Alseth]

Hi Andrew, I've edited my response for a proper workaround. I was able to connect and run the example properly now.

Cheers, Håkon

[Andrew]

Håkon,

Thank you again. I Verified this fixed the initial address problem however one problem still remains. On a hard reset or powered on with the switch on the DK, I get a hardfault traced from page_identify(). A soft reset does not cause this issue. I tried adding in some delays in main() but I get the same problem.

I am currently using a PCA10036 if that helps.

[DeanOSLI]

I am experiencing that exact same issue; hard reset no good, soft reset ok. PCA10040, SDK 11.0.0.2alpha. S132 2.0.0-7alpha

[Andrew]

I have spoken to Nordic support on this issue and without going into too much detail, there is not currently a way around this with GCC. They will continue to work through this issue. We should keep in mind that this is an experimental module that is also in an alpha SDK.