I'm trying to initialize a new sflash chip on an ISM43340. Reading the community content, I was able to determine how to add the flash chip and size to the Wiced configuration.
However, determining how to initialize the sflash chip for the first time, took several days of digging, and I'm not sure it's the correct change or in the proper place.
=== Solution ?? ===
The line below was added to initialize the sflash when running the make: snip.sflash_write-.
- Is this the correct change? Is this the correct placement?
../43xxx_Wi-Fi/platforms/ISM43340_M4G_L44/ISM43340_M4G_L44.mk
RESOURCES_LOCATION ?= RESOURCES_IN_WICEDFS
=== Fix Attempts ===
The first attempt was to run snip.ota_fr-ISM43340_M4G_L44 because that's what the documentation suggests to use to flash a new OTA app file. However, that failed because the wiced_apps_common.c / wiced_apps_get_size code isn't designed to detect an uninitialized sflash chip.
When building the sflash_write, the filesystem.bin file wasn't being generated nor was the sflash being initialized. See below for the missing messages. It took a couple of days to root cause the problem and find a possible solution. BTW, this sflash initialization worked fine out of the box for the eval board: CYW943907AEVAL1F, but not for the ISM43340.
=== wiced_apps_common.c / wiced_apps_get_size code improvement? ===
There was no indication of a problem when running the http://192.168.10.1/wiced_ota_server/upgrade.html that there was a problem with the sflash. The wiced_apps_get_size() code essentially went into a nearly infinite loop because the entire chip was set to all 1s. It seems feasible to add a code check to prevent this problem. The chip being used was (MX25U1633FM2I) apparently factory initialized to all 1s, because the error eventually found in debugging that (wiced_apps_get_size) method was reading all 1s for the app_header.count field. That is, under the assumption that all sflash chips are either factory initialized to all 1s or all zeros.... perhaps a code check would be helpful.
===wiced_apps_common.c / wiced_apps_get_size code suggested change ===
wiced_result_t wiced_apps_get_size( const image_location_t* app_header_location, uint32_t* size ) {
...
WICED_VERIFY( init_sflash( &sflash_handle, PLATFORM_SFLASH_PERIPHERAL_ID, ...));
WICED_VERIFY( sflash_read( &sflash_handle, app_header_location->detail.external_fixed.location, .......));
// code change here suggested checking for 255 or 0, which will be an error 99.999999% of the time
if (app_header.count > 254 || app_header.count == 0) return ERR_CODE_SFLASH_NOT_INITIALIZED;
=== The messages below would NOT appear in the make/build log until after adding the make file line as mentioned above
(RESOURCES_LOCATION ?= RESOURCES_IN_WICEDFS) ====
16:20:54.367 -> NO Support Range Erase Command!!
16:21:05.562 -> Waiting for command
............
Hello.
I bought CYW943907AEVAL1F .
I want to configure WICED_GPIO_39 as GPIO using
wiced_result_t wiced_result = wiced_gpio_init ( PIN_CS_MESSAGE_FPGA, OUTPUT_PUSH_PULL );
But I get wiced_result = 7 (Unsupported function)
WICED_GPIO_39 is at J6:11 on EVAL and it is named as SPI_1_MISO
Show LessTo anyone listening. We developed system using a Laird_EWB module. We used the EWB-DevKt to build some basic apps, Dual Mode BT, TCP Server, etc. I am currently using OLIMEX ARM-USB-TINY-H to debug in eclipse. We attempted to make this work with the standard WICED apps with no joy. I have two versions of wiced studio. One is vanilla which allows me to test a small dual mode bt app using the LAIRD DEV kit. The other wiced studio has been modified slightly to allow for the OLIMEX debugger. I am able to build and download in eclipse using OLIMEX with some issues that I have worked out. I begin debugging my app on OUR module and while progressing through the application I keep coming across two unhandled interrupts. The active interrupts are shown to be 33 and 54. I decided to tackle INTERRUPT 33 first. According 8to the STM32F412 manual this is associated with the I2C channel 2 event. When I created my own platform file, I did not include any I2C. I have two USARTS, JTAG header, and power, and a few jumpers. What I am looking for is the steps necessary to override the "unhandled interrupt" using the wiced platform. In fact if there is any manual or detailed document that provides the steps necessary to incorporate interrupts either RTOS or native, please let me know. I have been through WICED-101 but the info that I am looking for appears to be a little more in depth than what WICED-101 provides.
I have also successfully tested our UART app with RTOS with no issues. I would really appreciate if someone could throw me a bread crumb.
Many Thanks,
Dan T
Show LessHi everyone I'm trying to flash ISM43903_R48_L54 with a particular test target "flash_emc".
Building apps lookup table
make [1]: *** [download_dct] Error 1
make: *** [main_app] Error 2
make: *** [Makefile.wiced: 428: flash_emc] Error 2
I am under ubuntu 22.04 and the problem is present only with this target, with others the firmware is flashed correctly.
As you will see from the logs the wiced version is 4.1. Do you have any suggestions to try?
I started poking around to see if I can get my build files packaged up so we can use them during manufacturing. It looks like the normal build command doesn't create build/$project/APP.bin, but we use that to jlink flash controllers during manufacturing. I started poking around to see how it gets pulled in and it looked like adding either "download" or "package" should build it. I confirmed it happens during download (but that tries to actually use jlink and download to a device). I noticed just adding "package" doesn't do anything. After digging in more I noticed it was setup like this:
package: $(RELEASE_PACKAGE)
$(QUIET)$(ECHO) Created package successfully
$(RELEASE_PACKAGE): create_package_descriptor \
$(STRIPPED_LINK_OUTPUT_FILE) display_map_summary \
package_bootloader $(if $(findstring no_dct,$(MAKECMDGOALS)),,package_dct) package_app package_apps
in tools/makefiles/standard_platform_targets.mk, but RELEASE_PACKAGE isn't defined anywhere. If I pass in something defining it on the make line, I get the next issue:
make[1]: *** No rule to make target `create_package_descriptor',
I can't find any info on create_package_descriptor. I was wondering if this was meant to be removed and/or if I'm even going about this the right way. I'm currently using WICED-Studio-6.2.1.2 but I also tried on WICED-Studio-6.6.1 and saw the same issue. Any help or guidance would be appreciated.
Hi guys,
In our application, we connect to wifi AP and do stuffs. If we got some issues like request http error or disconnect with mqtt broker, we will retry to connect again. Incase retry not success we will disconnect with wifi AP and retry to connect current wifi AP again or connect the another wifi AP.
But sometime we got stuck forever in wiced_leave_ap.
I use CYW54907 with Wiced studio 6.6.
Show LessI'm trying to build up a test platform for our device off a raspberry pi which is running 32-bit Linux and is an ARM platform. I am trying to j-link flash the device from it. I copied over my build/, my apps/, and my tools/ folders but it looks like the ./tools/OpenOCD/Linux32/openocd-all-brcm-libftdi executible doesn't work on ARM.
Downloading Bootloader ...
./tools/OpenOCD/Linux32/openocd-all-brcm-libftdi: cannot execute binary file: Exec format error
**** OpenOCD failed ****
I don't believe that is built during the normal build process. I think it is just packaged with WICED Studio. Is there any way I can get flashing working on ARM 32-bit? I don't need it to build the full file, just be able to flash it. I'm currently running WICED-Studio 6.6.1
I just upgraded the version of Wiced we are using from 6.4 to 6.6.1.1. When the code tries to set wwd_wifi_fast_bss_transition_over_distribution_system the result is now WWD_WLAN_UNSUPPORTED.
The chip is a CY43012C0.
Any ideas why this no longer works?
Show LessHi,
Is there a clear centralized exhaustive list (and history) of know vulnerabilities in the CYW4343W (or all chips) firmware ?
Browsing https://github.com/Infineon/wifi-host-driver commits to RELEASE.md (like that Upload wifi-host-driver 1.94.0.6931 · Infineon/wifi-host-driver@19968e1 (github.com)) I can see that there is a few changelogs related to the CYW4343W firmware.
--- 7.45.98.120 ---
Fix pmk caching
--- 7.45.98.117 ---
Security fixes
Memory usage reduction by disabling debug features
--- 7.45.98.110 ---
Fixed zero stall on UDP
Fixed Tx traffic too less then RX
--- 7.45.98.95 ---
Fixed zero stall on UDP
--- 7.45.98.92 ---
Security fix (KRACK all-zero-key)
--- 7.45.98.89 ---
Security fix(Dragonblood WPA3 attack)
TCP Keepalive Implementation
Security fix(CVE-2019-9501 / CVE-2019-9502)
--- 7.45.98.81 ---
This list is not easy to build and browse, the known vulnerabilities should be centralized.
Is this list exhaustive ?
How can we know what version exactly fixes a vulnerability ? This only show ranges...
Between 7.45.98.110 and 7.45.98.117, it is only mentioned "Security fixes"... Where can we get more details on this/these vulnerability(ies) ?
Looking at this blog post (Potential Fragmentation Vulnerabilities for Wi-Fi ... - Infineon Developer Community), it looks like the CYW4343W could by affected. How can we make sure whether it is or not ?
Any more information about firmware vulnerabilities is welcome.
Thanks and best regards
Show Less