• State Verified Answer
  • Replies 16 replies
  • Subscribers 68 subscribers
  • Views 11892 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 111223
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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.

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
No Data
Related