We have found an issue within WICED Studio 6.6 where
GKI_find_buf_start() appears to be accessing an uninitized variable. We noticed that following a soft reset the RAM contents are not zeroed. Therefore GKI_find_buf_start() interpretation of the data leads to unpredicted behavior. The behavior tends to vary with changes to our application code, which is why we say it is unpredictable. However, the behaviour remains the same for each build. For example, in one case we found the BLE would not report the BTM_ENABLED_EVT following init.
Our temporary solution, given that fixing the
GKI_find_buf_start() function is not an option (black box), the only solution available was to ensure the data is initialised. The solution is then to write zeros in RAM during the initialisation sequence (
_start()), which fixes the issue.
/* Enable CPU Cycle counting */ CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; /* Global Enable for DWT */ DWT->CYCCNT = 0; /* Reset the counter */ DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; /* Enable cycle counter */ // Reset whole RAM memset((uint8_t *)SRAM1_BASE, 0, SRAM1_SIZE_MAX); memset((uint8_t *)SRAM2_BASE, 0, SRAM2_SIZE);
Can you please let us know the steps customer is using when they do a soft reset? Most likely the GKI buffer pool is not cleared or re-initialized but not sure?
Can you please let us know why you need to do a Soft reset?
The typical reason for soft reset is firmware upgrade (reboot to bootloader). The reset is performed through standard NVIC_SystemReset call.
The initialisation code for the MCU doesn't explicitly clear the RAM by default. Some GKI buffer related variables seem to not be initialized and in this case the program behavior indeed vary depending on the content of the RAM prior the soft reset. This is something that we usually do not see in development as the debugger tends to clear the RAM.
Thanks for your response.
Have you tried the project in old WICED SDK versions ? Just wanted to know if this issue came up only when you ported the project from an older sdk version to latest .
Also , can you confirm you are using latest WICED SDK version; which is 184.108.40.206 https://softwaretools.infineon.com/tools/com.ifx.tb.tool.wicedstudio
No, we are only using WICED Version: Wiced_006.006.000.0009.
Hi @mmch ,
Can you please test this in the latest release of WICED SDK 220.127.116.11 and see if the issue is reproducible as suggested by Anjana?
If it is still reproducible, please share with us a stripped down version of the project that showcases the issue. Also share with us the steps to reproduce the issue.
Sorry, I am not allowed to share code as it is confidential.
However, I think that you can easily reproduce the issue on your side with the information provided. One way would be to flash a firmware, enter debug, fill RAM with dummy value, reset PC, set a breakpoint in GKI_find_buf_start, look at the value of the variable on the first access. If it is filled with your RAM dummy value when read, it obviously means that it is read before being initialized.
Please let me know if this isn't clear.