- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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);
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello @RoHe_4370821
Can you please confirm which chipset you are using?
We will check this at our side and will update you.
Regards,
Anjana
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @AnjanaM_61,
Since it has been a month, do you have any news to share to that matter ?
Best regards,
Mehdi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @AnjanaM_61,
As my colleague, Mehdi said, it's a 4343W packaged into the MuRata 1DX module.
Regards,
Rob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello @RoHe_4370821
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?
Regards,
Anjana
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello @AnjanaM_61,
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.
Best regards,
Mehdi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mehdi,
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 6.6.1.1 https://softwaretools.infineon.com/tools/com.ifx.tb.tool.wicedstudio
Regards,
Anjana
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anjama,
No, we are only using WICED Version: Wiced_006.006.000.0009.
Best regards,
Mehdi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @mmch ,
Can you please test this in the latest release of WICED SDK 6.6.1.1 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.
Bragadeesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @BragadeeshV,
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.
Best regards,
Mehdi