Now we already move our application to sdk-5.2.0, but due to this issue we cannot
distribute our firmware.
Can someone tell when will this get fix?
Also please don't break compatibility for any reason.
At least you need to provide an option to avoid breaking compatibility with older sdks for existing users.
Now I regret move our application to sdk-5.2.0 due to this issue and some new TLS issues.
I tried various ways to get response, however I don't get any valid fix.
Can you at least let me know if you are going to fix this or not.
If you are going to fix it, when will be the fix available.
We cannot wait endless, so we need to know if we have to use older SDK version or if
cypress can provide the fix or provide new release ASAP.
The issue with older SDK is mainly I'm afraid cypress won't provide any bug fix.
Especially, the LTS library is complete changed.
From other thread I got information that the upcoming WICED Studio 6.0 release, scheduled for October 28.
Just one thing I need to get confirm:
Will the new release fix the clm download blob file in resource filesystem issue?
I have descibed the problem here: https://community.cypress.com/message/142764#142764
I do very worry about this issue.
I will need to check on this.
I had reported this for 2 months, but don't get any valid feedback.
You can also check MyCase 00371811, where the only response I got was
1 month ago mentioned that this issue was discussing internally.
(I also have suggestions about addressing this issue, but no feedback at all.)
It's really very frustration about such situation.
So I just test it with sdk-6.0.0 and confirm this issue still there.
This is a *blocking* issue for us and that is why I even emailed to you guys via
private emal and submitted to SPDF system.
Note, I even cannot use older sdk because of KRACK issue.
What do you suggest now?
Can you just provide a build option to disable clm_blob download?
It wont' be too hard.
Sigh, We spent too much time in waitting the fix.
In WICED SDK 6.0, some resources can be placed in direct resources. So you can place the WLAN firmware, CLM blob into direct resources instead of WICEDFS. You can use the macro INTERNAL_MEMORY_RESOURCES in platform makefile to add the resources as shown below:
INTERNAL_MEMORY_RESOURCES = resources/firmware/$(WLAN_CHIP)/$(WLAN_CHIP)$(WLAN_CHIP_REVISION)$(WLAN_CHIP_BIN_TYPE).bin resources/firmware/$(WLAN_CHIP)/$(WLAN_CHIP)$(WLAN_CHIP_REVISION)$(WLAN_CHIP_BIN_TYPE).clm_blob
A whitespace is used to separate the resources.
In WICED SDK 6.0, some resources can be placed in direct resources. So you can place the WLAN firmware, CLM blob into direct resources instead of WICEDFS. You can use the macro INTERNAL_MEMORY_RESOURCES in platform makefile to
That does not work.
Basically, the wlan firmware is quite big so it's not suitable to be in
direct resources. So in our case, we put wlan firmware in a seperate
section by setting MULTI_APP_WIFI_FIRMWARE.
The INTERNAL_MEMORY_RESOURCES requres GLOBAL_DEFINES += WWD_DIRECT_RESOURCES to
work. Define WWD_DIRECT_RESOURCES then WIFI_FIRMWARE_IN_MULTI_APP won't work.
In additional, using direct resource means it needs 2 copy of the CLM blob.
(One for application firmware, one for factory reset default firmware.)
The most simple solution is don't separate CLM blob.(Just like the wlan firmware in sdk-5.1)
1 of 1 people found this helpful
Please check release notes Release Notes: WICED Studio 6.0.0 section 5.3 Infrastructure.
I know the documentaion.
It's wrong. It does not consider the case using
INTERNAL_MEMORY_RESOURCES and WIFI_FIRMWARE_IN_MULTI_APP at the same time.
see, it even won't pass compilation:
build/snip.scan-FreeRTOS-LwIP-43438/libraries/STM32F4xx.a(wwd_resources.o): In function `host_platform_resource_read_direct':
/home/axel/Documents/WICED-Studio-6.0/43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/../wwd_resources.c:140: undefined reference to `wifi_firmware_image'
make: *** [build/snip.scan-FreeRTOS-LwIP-43438/binary/snip.scan-FreeRTOS-LwIP-IGS02.elf] Error 1