AIROC™ Wi-Fi MCUs Forum Discussions

Are there any examples or guides for designing a system with a PSoC based BLE and a WiFi only CYWxx907 based radio module?

I'd like to pair either a PSoC 4 BLE or a PSoC 6 BLE to a CYW43907 based Murata Type 1GC WiFi module.

I'm specifically interested in methods to handle coexistence.

Greg

We are encountering random failures with products using the CYW43907 and WICED where the Reception of frames seems to be unhandled resulting in connectivity issues. From Wireless captures, everything is operating fine until application layer TCP packets stop being received and even 802.11 management and action frames appear to be missed. I have captured missed 802.11 action packets (bulk ack) being retried by the AP and  even 802.11 deauth frames being resent by the AP. Since this is happening with 802.11 management and action frames, i am thinking this looks more like a WLAN core issue.

Our devices are stationary and had great RSSI prior to the issue, and no change in the environment so it isn't RF, like the station roamed out of coverage. 

The network consist of Aruba AP's running an open network and DCHP. 

Prior to the problem, per the wireless captures, there was no AP roaming, hand-offs, or DHCP renewals occurring. 

Has anyone encountered this? These devices are running WICED 6.2.1.

To whom it may concern, I have recently purchased one fo your products - CYW43907 (dual-band Wi-Fi soC), and been testing its performanceon a dedicated kit -CYW943907AEVAL1F (as suggested on Infineon official website). I am writing to address several issues I encountered during testing the product's WLAN 2.4 GHz receiver performance which conflicts with the specifications started within the datasheet you provide.
In your datasheet (page 53) it is stated that the sensitivity (measuredon 8% PER) in 1 Mbps DSSS mode is typically -98.9 dBm (no maximum value provided). To test this, I used a CMW290 Functional Radio Communication Tester as an AP which sent data packets and calculated PER by counting ACKs (acknowledgements) received from the DUT (CYW43907). The DUT was connected to the CMW by RF cable which attenuation was considered during our testing. PER was calculated in various 2.4 GHz Wi-Fi channels as function of the input power. By examining the results, it appears that there are two unexplained phenomenons occuring in every channel. At input power level of -76 dBm there is a PER of 80%, which is 22 dB above the -98 dBm sensitivity stated in the datasheets.
In addition, below -76 dBm there are "spikes" of PER appearing every 1 dB drop in the input power level (I assume this can beas a result of an unstable feedback loop in the AGC).
I would greatly appreciate ifyou can address these issues in detail and suggested methods to fix them.
Best regards,
Eli

Using a CYW43907 based radio module; What is the proper way to add functions onto pins?

A) Drive the pin directly by first initializing then toggling it.

-  Initializing and driving seems to work for several GPIO pins I tried including GPIO_0, GPIO_8, GPIO_10 and GPIO_12. I can initialize these pins, toggle them, then observe the output using CYW943907AEVAL1F kit. Disclaimer: I haven’t yet observed the toggling of GPIO_8 as that signal isn’t easy to probe before it goes through a switch chip at U15.

- Initializing fails for PWM_5. Starting with TCP_Server and CYW943907AEVAL1F, attempting to initialize PWM_5 hangs the code.

Following code added to TCP_SERVER Project main.c file for CYW943907AEVAL1F.

=================================

cy_rslt_t result;

result = cyhal_gpio_init( PIN_GPIO_12, CYHAL_GPIO_DIR_OUTPUT, CYHAL_GPIO_DRIVE_STRONG, false );

if( result == CY_RSLT_SUCCESS )

printf( "   PIN_GPIO_12 Initialization succeeded.\r\n" );

else printf( "   PIN_GPIO_12 Initialization failed.\r\n" );

cyhal_gpio_toggle( PIN_GPIO_12 );

=================================

GPIOs 12, 10, 0 and 8 initialize and send text to terminal window on PC

Observed signals: GPIO_10 @ J12-4, GPIO_12 @ J12-5 and GPIO_0 @ J10-1 toggle as expected. I haven’t found an easy way to probe GPIO_8 before U15.

B) Drive a signal that can be multiplexed onto the pin

Since I can’t find what else is driving PWM_5, and I can’t reinitialize it, I’d like to try to multiplex onto it.

How can I re-assign PWM_5 to use it as a GPIO?

When the following code to initialize PWM_5 is active, the radio locks up. The code builds fine, programs and runs through the point where it prints “Ready to initialize PIN_PWM_5” to the terminal. Then appear to stop.

=================================

printf( "   Ready to Initialize PIN_PWM_5.\r\n" );

result = cyhal_gpio_init( PIN_PWM_5, CYHAL_GPIO_DIR_OUTPUT, CYHAL_GPIO_DRIVE_STRONG, false );

if( result == CY_RSLT_SUCCESS )

printf( "   PIN_PWM_5 Initialization succeeded.\r\n" );

else printf( "   PIN_PWM_5 Initialization failed.\r\n" );

=================================

Is there an Application Note that describes the method to multiplex pins using ModusToolbox?

Note: I do have a separate question into the community on formart required for multiplexing @ Format of code to Multiplex pins using ModusToolbox

Greg

Hello.

I'm using I2C on CYW954907EVAL1F as SMBUS

to comunicate with RRC2054: it is a smart battery.

The communication doesn't work.

I notice that I2C-DATA toggle when I2C-CLK has a falling edge:

does this lead to a misinterpretation at slave side ?

(E.g. can interpreted as I2C - START or I2C - STOP conditions ?)

Is there a way to configure the CYW954907EVAL1F microcontroller to force I2C-DATA to toggle when I2C-CLK is Low ?