Configuration of gzp_dynamic_pairing project for device in segger embedded studio environment

[astella]

Thank you Nordic team for your precious help. Is by any chance the project sdk_15_gzp_dynamic_pairing_ses_device.zip also available to download? Is there any particular reason why both these _ses projects are not by default provided inside the latest sdk (15.3)? Inside the keil gzll device project I can see these preprocessor symbols:

BOARD_PCA10056 BSP_SIMPLE CONFIG_GPIO_AS_PINRESET FLOAT_ABI_HARD GAZELL_ALTERNATIVE_RESOURCES GAZELL_PRESENT NRF52840_XXAA SWI_DISABLE0 USE_SD_HW_RESOURCES _HEAP_SIZE=8192 _STACK_SIZE=8192

Being the macro SOFTDEVICE_PRESENT not defined, as well as the NO_VTOR_CONFIG one, may you please confirm that the precompiled library gzll_nrf52840_sd_resources_gcc.a doesn't make use of the SoftDevice (s140 for pca10056 board)? If so, the sd prefix in the name of the library seems to be a little bit confusing. In this case (SoftDevice not used) can I safely use the following simple linker section placement macro:

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x100000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x40000;FLASH_START=0x0;FLASH_SIZE=0x100000;RAM_START=0x20000000;RAM_SIZE=0x40000"
linker_section_placements_segments="FLASH RX 0x0 0x100000;RAM RWX 0x20000000 0x40000" ?

It is very important to understand how to properly set memory for the gzll device project. I had it already up and running in the ses environment, nevertheless the program was not able to correctly start an encrypted dialogue with the host. Apparently many routines in gzp.c file failed when calling memcpy: the routine was not able to copy memory in the right way, even when I used a custom memcpy implementation. May I ask if the information reported in the linker section placement macro is always in synch with the content of the .emProject xml file? The .emProject xml file should never be edited by hand? 

In your project gzll_ack_payload_device_pca10056 (that does use the gzll_nrf52840_sd_resources_gcc.a library) I also found inside the .emProject file:

c_preprocessor_definitions="BOARD_PCA10056;CONFIG_GPIO_AS_PINRESET;FLOAT_ABI_HARD;GAZELL_ALTERNATIVE_RESOURCES;GAZELL_PRESENT;INITIALIZE_USER_SECTIONS;NO_VTOR_CONFIG;NRF52840_XXAA;SWI_DISABLE0;USE_SD_HW_RESOURCES;"  and

linker_section_placement_macros="FLASH_PH_START=0x0;FLASH_PH_SIZE=0x100000;RAM_PH_START=0x20000000;RAM_PH_SIZE=0x40000;FLASH_START=0x0;FLASH_SIZE=0x100000;RAM_START=0x20000000;RAM_SIZE=0x40000"

I just got started using a clean gzll_ack_payload_device_pca10056 as a template project. In order to build the dynamic pairing device program, I had to copy the nrf_gzp_config.h file, add a gzp include directory, add nrf_gzp.c, nrf_gzp_device.c, nrf_ecb.c and nrf_nvmc.c. The project does build successfully, I'm trying to debug it, though. As it keeps going hardfault, using all other default configurations, when in Release mode. When in Debug mode the program seems to run but the gazell device transmission is like transparent to the host device (even if they share the same secret key and other parameters in nrf_gzp_config.h). Evidently the device it is not transmitting at all because of some internal error. I have to say that I'm sure that must be some issue about the device project configuration, in fact I proved the ses gzll dynamic pairing host project working putting it to the test using the device flashed with the binary as it comes from the Keil environment.

From the linker file for the IAR environment is it possible to see:

keep { section gzp_dev_data };
place at address mem:0x1000 { readonly section gzp_dev_data };
keep { section gzp_dev_data_sd };
place at address mem:0x15000 { readonly section gzp_dev_data_sd };

Perhaps it is this key information that is missing right now. Do you give this information through the flash_placement.xml file in the segger embedded environment? I have got the same flash_placement.xml file for the ses host project and the device one. In particular the <ProgramSection alignment="4" keep="Yes" load="No" name=".GZP_PARAMS" start = "0x00015000" size="0x1000" /> program section tag is present, though.

I also tried using the ble_app_gzll_pca10056_s140 as a starting point template, in order to have the gzll device dynamic pairing example working. This time, using default configurations and after adding a couple of existing drivers, I got the project apparently partially working and the device, when compiled in Release mode, was able to receive Host Id. Neverthless, the encrypted transmission doesn't work again and Debug mode keeps going hardfault. Forcing the debug in Release mode, even if optimizations are enabled, I see that after the gzp_add_validation_id function call the validation id seems that is not copied at all (it is always 0xff 0xff 0xff). 

Thanks in advance for taking the time to reply 

[bjorn-spockeli]

Is by any chance the project sdk_15_gzp_dynamic_pairing_ses_device.zip also available to download? Is there any particular reason why both these _ses projects are not by default provided inside the latest sdk (15.3)?

 Are you referring to device counterpart the the .zip file that was posted in this DevZone case?  If its not in the SDK then its probably because its an example that was made by our Tech Support department and is not a part of the official SDK. 

Being the macro SOFTDEVICE_PRESENT not defined, as well as the NO_VTOR_CONFIG one, may you please confirm that the precompiled library gzll_nrf52840_sd_resources_gcc.a doesn't make use of the SoftDevice (s140 for pca10056 board)? If so, the sd prefix in the name of the library seems to be a little bit confusing.

 The gzll_nrf52840_sd_resources_gcc.a uses the same hardware resources as our SoftDevice, meaning that it can be used for GZLL only applications or GZLL concurrently with Bluetooth. 

If its a GZLL only device, then you should use the following preprocessor defines on a NRF52840 DK 

BOARD_PCA10056
CONFIG_GPIO_AS_PINRESET
FLOAT_ABI_HARD
GAZELL_ALTERNATIVE_RESOURCES
GAZELL_PRESENT
INITIALIZE_USER_SECTIONS
NO_VTOR_CONFIG
NRF52840_XXAA
SWI_DISABLE0
USE_SD_HW_RESOURCES

and 

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x100000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x40000
FLASH_START=0x0
FLASH_SIZE=0x100000
RAM_START=0x20000000
RAM_SIZE=0x40000

 

May I ask if the information reported in the linker section placement macro is always in synch with the content of the .emProject xml file? The .emProject xml file should never be edited by hand? 

 The linker section placement macros are edited in the project settings in SES, which changes the .emProject xml file. It is possible to do the changes by hand, but i recommend going through the Project settings GUI. 

I just got started using a clean gzll_ack_payload_device_pca10056 as a template project. In order to build the dynamic pairing device program, I had to copy the nrf_gzp_config.h file, add a gzp include directory, add nrf_gzp.c, nrf_gzp_device.c, nrf_ecb.c and nrf_nvmc.c. The project does build successfully, I'm trying to debug it, though. As it keeps going hardfault, using all other default configurations, when in Release mode. When in Debug mode the program seems to run but the gazell device transmission is like transparent to the host device (even if they share the same secret key and other parameters in nrf_gzp_config.h). Evidently the device it is not transmitting at all because of some internal error. I have to say that I'm sure that must be some issue about the device project configuration, in fact I proved the ses gzll dynamic pairing host project working putting it to the test using the device flashed with the binary as it comes from the Keil environment.

 

I also tried using the ble_app_gzll_pca10056_s140 as a starting point template, in order to have the gzll device dynamic pairing example working. This time, using default configurations and after adding a couple of existing drivers, I got the project apparently partially working and the device, when compiled in Release mode, was able to receive Host Id. Neverthless, the encrypted transmission doesn't work again and Debug mode keeps going hardfault. Forcing the debug in Release mode, even if optimizations are enabled, I see that after the gzp_add_validation_id function call the validation id seems that is not copied at all (it is always 0xff 0xff 0xff). 

Can you provide the call stack and CPU registers when the hardfaults occurs. Even better would be if you could attach the projects and then we could debug them here for you. 

 

[astella]

/cfs-file/__key/communityserver-discussions-components-files/4/device.zip/

cfs-file/__key/communityserver-discussions-components-files/4/host.zip

Thanks bjorn-spockeli for taking the time to reply to me, thanks to all guys of the Nordic support team. Yes, exactly, the host project i was refferring to is the project that comes from the link you correctly pointed out, and kindly offered
from Nordic itself.
I put here in attachment a version slightly modified of it so that it was possible to have it up and running for me. The zip version may be directly unzipped inside the folder
proprietary_rf/gzll/gzp_dynamic_pairing that comes from nRF5_SDK_15.2.0_9412b96.
As I previously said this host project has been tested programming a PCA10040
board as a host and using as a device counterpart a PCA10056 board flashed with the device project
binary that comes from the keil environemnt inside the Nordic SDK.

I attached one of the device versions that I was trying to have up and running.
It comes from nRF5_SDK_15.3.0_59ac345/.../proprietary_rf/gzll_ack_payload/device
Hope that you can please me some advice about how to correctly configure the project for the
PCA10056 so that it works when speaking gzll with the host previously set up.
Thank you so much for your help. Any advice will be more than appreciated.

They should have the same
nrf_gzp_config.h
flash_placement.xml using the <ProgramSection alignment="4" keep="Yes" load="No" name=".GZP_PARAMS" start = "0x00015000" size="0x1000" />
tag
This is the
Section placement macros for the device:
FLASH_PH_START=0x0
FLASH_PH_SIZE=0x100000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x40000
FLASH_START=0x0
FLASH_SIZE=0x100000
RAM_START=0x20000000
RAM_SIZE=0x40000
And preprocessor definitions:
BOARD_PCA10056
CONFIG_GPIO_AS_PINRESET
FLOAT_ABI_HARD
GAZELL_ALTERNATIVE_RESOURCES
GAZELL_PRESENT
INITIALIZE_USER_SECTIONS
NO_VTOR_CONFIG
NRF52840_XXAA
SWI_DISABLE0
USE_SD_HW_RESOURCES
It has got 1024 kB heap - stack (I also used other dimensions too)
I have not Link time optimization and no optimization level
Build ---> Memory segments:
FLASH RX 0x0 0x100000
RAM RWX 0x20000000 0x40000
.GZP_PARAMS RWX 0x00015000 0x1000

Maybe my memory segments definition is wrong; being .GZP_PARAMS zone inside the FLASH one I need to properly specify this aspect.Should be the case, what is the correct syntax to adopt?

[astella]

Hi  bjorn-spockeli is there any update on the subject, please?We are evaluating the chance to use nRF52840 and gazell instead of nRFLU1+ for our next production.It would be nice to have any update so that we can go further in our evaluating process, to also understand what are the software tools and ecosystem that we are gonna using for our work. Having said that we really appreciate the stunning quality of Nordic hardware, so thanks for your work and any suggestion is really appreciated. Cheers 

[bjorn-spockeli]

Hi Astella,

I sincerley apologize for the very very late reply. Are you still having issues with setting up the host on the nRF52840 in SES?

Best regards

Bjørn

[astella]

Hi bjorn-spockeli , yes, we stopped using gzll gzp_dynamic_pairing in SES environment. But we are really really interested in it. Hope you can give us some help. Thanks for replying and looking forward to hear from you again

[bjorn-spockeli]

HI Astella, 

Sorry for the late reply again. I will try to look at this mid-next week when I am back from vacation. 

Bjørn

[astella]

Ok, thank you. We are working every day using your products and it is a pleasure to use them for hw performances and software ecosystem. I must say that this particular problem was the only one we got stucked for a while. Still we didn't solved it, we also had to follow other projects though, as you can imagine. Thank you for your work, hope to hear from you soon.