Configuration of gzp_dynamic_pairing project for device in segger embedded studio environment 2

[astella]

To the kind attention of Nordic support team,

I'd like to open a new thread after the first one (https://devzone.nordicsemi.com/f/nordic-q-a/46318/configuration-of-gzp_dynamic_pairing-project-for-device-in-segger-embedded-studio-environment), wishing that this time every thing could be set and working. I uploaded two slightly modified versions of what I had already modified a little bit about 8 month ago. I got something that it is some how working, I can receive encrypted msgs also, but only when:

//#define GZP_VALIDATION_ID {0x32, 0x53, 0x66} ///< Validation ID. Required to be shared by Host and Device. Not a secret.
#define GZP_VALIDATION_ID {0xFF, 0xFF, 0xFF} ///< Validation ID. Required to be shared by Host and Device. Not a secret. in nrf_gzp.h header file.

And:

//#define GZP_SECRET_KEY {1, 23, 45, 57, 26, 68, 12, 64, 13, 73, 13, 62, 26, 45, 12, 77}
#define GZP_SECRET_KEY {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}.

When both GZP_VALIDATION_ID and GZP_SECRET_KEY are both 0xFF, then the two program seems to be working. I mean, there is no any crash and routines seem to be properly coded in the libraries (*_gcc.a). It seems that the info about the gpio state is properly transmitted also, so the transmission seems to be working. But the fact that everything is fine when those parameters are both set to 0xFF make me think that something fails in the key exchange, or maybe something it is not properly written in the flash of devices. So that having all relevant parameters to 0xFF makes no difference. But I'm only thinking, I should debug more next days. 

Of course you know this valuable piece of software way better than me. May you please give me a hand to understand how to solve this issue? I'll be working a little bit on these uploaded files next days, should I have any news, I'll be posting it here; hope that you can also give me a feedback about the working of the uploaded projects. Thanks to you all for your valuable work.

I had the host project running on a PCA10040 board and the device project running on a PCA10056 board.

host03122019.zipdevice03122019.zip

[astella]

It could also be an issue with the memcpy like functions. It seems that they are not doing their work

[astella]

Unfortunately, I saw that after calling gzp_erase_pairing_data() it seems that flash is not read up correctly anymore.

That is way when all parameters are set to be all 0xFF things seems to be some how working. In theory, what can destroy access to flash? Maybe flash is not accessible correctly anymore when using a SoftDevice? Maybe the application is not linked correctly.

Simple tests

extern const uint8_t gzp_validation_id[GZP_VALIDATION_ID_LENGTH];
int main(void)
{

bool tx_success = false;
bool send_crypt_data = false;
gzp_id_req_res_t id_req_status = GZP_ID_RESP_NO_REQUEST;

unsigned char *pC = (unsigned char *) &gzp_validation_id[0];

unsigned char pC1 = gzp_validation_id[0];
unsigned char pC2 = gzp_validation_id[1];
unsigned char pC3 = gzp_validation_id[2];

// Data and acknowledgement payloads
uint8_t payload[NRF_GZLL_CONST_MAX_PAYLOAD_LENGTH]; ///< Payload to send to Host.

// Set up the user interface (buttons and LEDs)
app_timer_init();
ui_init();
*pC = (unsigned char *) &gzp_validation_id[0];

pC1 = gzp_validation_id[0];
pC2 = gzp_validation_id[1];
pC3 = gzp_validation_id[2];

// Initialize the Gazell Link Layer
bool result_value = nrf_gzll_init(NRF_GZLL_MODE_DEVICE);
GAZELLE_ERROR_CODE_CHECK(result_value);

*pC = (unsigned char *) &gzp_validation_id[0];

pC1 = gzp_validation_id[0];
pC2 = gzp_validation_id[1];
pC3 = gzp_validation_id[2];

// Attempt sending every packet up to MAX_TX_ATTEMPTS times
nrf_gzll_set_max_tx_attempts(MAX_TX_ATTEMPTS);

result_value = nrf_gzll_set_timeslot_period(NRF_GZLLDE_RXPERIOD_DIV_2); // Half RX period on nRF24Lxx device
GAZELLE_ERROR_CODE_CHECK(result_value);

// Erase pairing data. This example is intended to demonstrate pairing after every reset.
// See the gzp_desktop_emulator example for a demonstration on how to maintain pairing data between resets.
// gzp_erase_pairing_data();
*pC = (unsigned char *) &gzp_validation_id[0];

pC1 = gzp_validation_id[0]; ???
pC2 = gzp_validation_id[1]; ???
pC3 = gzp_validation_id[2]; ???

// Initialize the Gazell Pairing Library
gzp_init();

*pC = (unsigned char *) &gzp_validation_id[0];

pC1 = gzp_validation_id[0];
pC2 = gzp_validation_id[1];
pC3 = gzp_validation_id[2];

result_value = nrf_gzll_enable();
GAZELLE_ERROR_CODE_CHECK(result_value);

*pC = (unsigned char *) &gzp_validation_id[0];

pC1 = gzp_validation_id[0];
pC2 = gzp_validation_id[1];
pC3 = gzp_validation_id[2];

pC1 = pC[0];
pC2 = pC[1];
pC3 = pC[2];

for (;;)
{

[Kenneth]

I notice you mention softdevice, the softdevice needs to be disabled while using gzp, since the gzp access the flash directly through nrf_nvmc module (this is not allowed when softdevice is enabled). I assume you have checked that nothing else is stored to the configured GZP_PARAMS_STORAGE_ADR (0x00015000), for instance I would expect that if you have a softdevice present that will take up more than address 0x00015000 by default. So I suggest to move GZP_PARAMS_STORAGE_ADR way back in the flash area if you have softdevice + application, but not too far back if you have Bootloader or use FDS in addition, since that may also use flash pages at the end. 

[astella]

Thank you Kenneth for your kindness. Not having Keil, I opened gzll_dynamic_pairing_device_pca10056.uvprojx file with a text editor.

I can see that this options are used:

1.              <Define> 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</Define>

I assume it should be safe to use the very same options for the segger embedded studio device project.

2.This is the library, compiled with Keil toolchain compiler:

gzll_nrf52840_sd_resources_arm.lib

I assume that I have to use the same _gcc.a in segger embedded studio.

3. For the device segger project I'm going to use the same sdk_config.h that is used in the host project that you provided in a link here in the Nordic dev zone. I assume that in this way I should be using the very same resources.

4. Maybe I can double check the linker file. I see in the gzp_device_iar_nrf52.icf there is a gzp_dev_data section at 0x1000 e gzp_dev_data_sd section a 0x15000.

In my device flash_placement.xml I only have got     <ProgramSection alignment="4" keep="Yes" load="No" name=".GZP_PARAMS" start = "0x00015000" size="0x1000" />

Maybe the gzp_dev_data section at 0x1000 is missing?