stack bss memory issue working on gzp example using segger environment

[astella]

To the kind attention of Nordic support team,

I have got a project with this memory configuration

and this

<!DOCTYPE Linker_Placement_File>
<Root name="Flash Section Placement">
<MemorySegment name="FLASH" start="$(FLASH_PH_START)" size="$(FLASH_PH_SIZE)">
<ProgramSection alignment="0x100" load="Yes" name=".vectors" start="$(FLASH_START)" />
<ProgramSection alignment="4" load="Yes" name=".init" />
<ProgramSection alignment="4" load="Yes" name=".text" />
<ProgramSection alignment="4" load="Yes" name=".dtors" />
<ProgramSection alignment="4" load="Yes" name=".ctors" />
<ProgramSection alignment="4" load="Yes" name=".rodata" />
<ProgramSection alignment="4" load="Yes" runin=".fast_run" name=".fast" />
<ProgramSection alignment="4" load="Yes" runin=".data_run" name=".data" />
<ProgramSection alignment="4" load="Yes" runin=".tdata_run" name=".tdata" />
<ProgramSection alignment="4" load="No" name=".GZP_PARAMS" start="0x09000" size="4096" />
</MemorySegment>
<MemorySegment name="RAM" start="$(RAM_PH_START)" size="$(RAM_PH_SIZE)">
<ProgramSection alignment="0x100" load="No" name=".vectors_ram" start="$(RAM_START)" address_symbol="__app_ram_start__"/>
<ProgramSection alignment="4" load="No" name=".bss" />
<ProgramSection alignment="4" load="No" name=".fast_run" />
<ProgramSection alignment="4" load="No" name=".data_run" />
<ProgramSection alignment="4" load="No" name=".tdata_run" />
<ProgramSection alignment="4" load="No" name=".tbss" />
<ProgramSection alignment="4" load="No" name=".non_init" />
<ProgramSection alignment="4" size="__HEAPSIZE__" load="No" name=".heap" />
<ProgramSection alignment="4" size="__STACKSIZE__" load="No" place_from_segment_end="Yes" name=".stack" address_symbol="__StackLimit" end_symbol="__StackTop"/>
<ProgramSection alignment="4" size="__STACKSIZE_PROCESS__" load="No" name=".stack_process" />
</MemorySegment>
</Root>

flash_placement.xml files. What it happens is that if I put a little array in stack memory the program seems to go ok, both encrypted and non encrypted communications works very well.

If I put the very same array in .bss memory, the encrypted communication keeps working, but nrf_gzll_add_packet_to_tx_fifo fails after one or two good communications. If I add another

array in stack and I give this address to nrf_gzll_add_packet_to_tx_fifo, then it works ok again. It seems that the routine needs a stack address. It is really strange behaviour, I don't know what to think.

What could theoretically be? Basically I'm evaluating the standard gzp program device host program in Segger environemnt and the little array I'm moving around is the 32 byte gazell payload one. Obviously, I'm not 100% sure of device configuration, it being excluded from SDK in its segger incarnation.

Hope you could give me a theoretically hint about memory configuration. Thank you for your kindness

[astella]

I had slightly modified the standard project in order to have the host replying to the device, in order to have a bidirectional communication. And it works pretty well when the device payload array is put in .stack memory. I'm going back the complete standard project to see if these little modifications causes the trouble. Still, it appears to be amazing, that putting the payload array as previously described in stack memory it works.

Yes I saw that removing the bidirectional communication, I can put the device payload array where I want. It is very strange, though I create some sort of instability, probably not implementing the bidirectional communication in the right way, and I was aware of this only moving things in ram in the device project. If I stayed if the device payload array in .stack it was working. moving it in bss made the instability due to my bidirectional implementation clear!

Sorry if I was not able to explain what it is happening in a good descripting way. Feel free to ask me further if you feel like you can understand what it is happening in here. Thank you for all work

[astella]

In the device code I reset length before and after calling nrf_gzll_fetch_packet_from_rx_fifo. Maybe, the position of payload in SRAM  memory is important because length parameter might be uploaded with strange values, when library is receiving?

length = 32;
if ((nrf_gzll_fetch_packet_from_rx_fifo(UNENCRYPTED_DATA_PIPE, payload75, &length)) == true)
{
if(memcmp(payload75, "astella", 9))
{
unsigned int stop = 0;
}
else{
unsigned int comm_ok = 0;
}
for(i = 0; i < 32; i++)
payload75[i] = 0;
length = 0;
myCount++;
}
}
length = 32;

This seems to solve the issue