Pairing code examples for an NRF51822 based peripheral.

[Robin]

Hello nRF world,

We have custom peripheral board based on the nRF51822 and need to be able to pair it with a host.  Does anyone have a well documented example of code for doing so?

Thank you kindly,

Robin@TL

[Robin]

An update:  I have taken the advice of a related ticket and merged our code into the ble_app_gls example to attempt pairing. 

However, although all modules compile independently, there appears to be a memory segmentation problem when linking.  It appears to be associated with the fstorage for fds code, but I cannot determine the fix.  The initial error messages are as follows:

Output/Debug/Exe/iDrink.elf section `.fs_data' will not fit in region `UNPLACED_SECTIONS'

Subsequently several errors ensue...

region `UNPLACED_SECTIONS' overflowed by 16 bytes

Output/iDrink Debug/Obj/fstorage.o: In function `check_config':

undefined reference to `__start_fs_data'

undefined reference to `__stop_fs_data'

... and on ad-nauseam...

What file might I be missing to define this unplaced section in memory?

Thanks again, in advance,

Robin@TL

[Susheel Nuguru]

You just needed to add one line in flash_placement.xml file in your project

  <MemorySegment name="$(FLASH_NAME:FLASH)">
    ....
    ....
	<ProgramSection alignment="4" keep="Yes" load="Yes" name=".fs_data" address_symbol="__start_fs_data"  end_symbol="__stop_fs_data" />
  </MemorySegment>

After that your project compiles fine.

...

[Robin]

Hello Susheel,

Thank you for getting me straight on this one.  I guess my old school thinking had me looking for a header or linker directive in an ld file, not in an xml.. Oh well,...

So now to the next problem:

There is a "retarget.c" file in the build list that will not compile.  I am not sure what is being retargeted.  Please explain.  I had it excluded to get to where I was.  When I include it here is the error messages:

storage size of '__stdout' isn't known

storage size of '__stdin' isn't known

at these lines:

FILE __stdout;
FILE __stdin;

I am not sure if this file is "needed" for pairing/bonding, but thought I should ask before moving on to test.

Thanks

Robin@TL

[Robin]

Hello again Susheel,

In anticipation of your answer regarding the "retarget.c" file necessity for pairing, I did get the app to build,  However, I see no advertisement for pairing, nor does the uart path work any longer.  I can easily go back and forth just by including/excluding the appropriate main.c file, so if you have any suggestions to try, I am prepared.  One of the things I did note is that the RAM definition for the gls app is considerably higher than the for the uart app.  I am not sure if it is required, but it does build and upload at the lower memory setting, but still wont run.

On a more general point, I am not sure how to determine the memory size requirement and then to make sure that the IDE properly allocates appropriately.  If you can help me learn these details it of of this, it would be greatly appreciated.

Thanks again,

Robin@TL

[Susheel Nuguru]

this is to retarget your printf to UART instead of __stdout. 

If you do not use printf, then remove it without hesitation.

[Robin]

Hello Susheel,

Our code does not use printf, but all of the sdk logging functions do.

What needs to be done to make this retarge work so we can see errors that may occur? 

This seems it could be very helpful in debugging.  I see that the sdk 12.3 retarget.c is considerably different. Are there any known problem with the sdk 11 version?

[Robin]

Hello again Susheel,

Just a note to let you know that I have found reference to SES have an alternative to printf for development.  Not sure what will happen when we go to production code, with all the printf's in the sdk stuff, but for now I an not concerned about retarget.  I am however having issues trying to use our newly acquired pca10031 dongle to redirect the data stream from our uart to a terminal emulator on our pc.  There is a tutorial for this, but the terminology used does not match the latest nrf connect gui, so interpreting gets very guessing.  I will open a new case for this one in hope we can get the data we need from our board to a pc for analysis.

Thanks

Robin@TL