stack bss memory issue working on gzp example using segger environment

Question

To the kind attention of Nordic support team, I have got a project with this memory configuration and this 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 · Accepted Answer

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

stack bss memory issue working on gzp example using segger environment

Top Replies