Wi-Fi Combo

To 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

Hi 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.

I'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?

Hi,

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