Dear Sir, 

If we do not program the address from 0x4001 to 0x402E, 

does it will effect the IC movement?

Best regards,

Lillian 

When i enable OTP function by EZ-PD configuration utility ,

There have two parameters, one is "cut off" , another is "Restart value"

How to set those parameters? What is the unit?

The FW use "pd_hal_measure_internal_temp" function to get internal temperature.

The function return value unit is ℃, right ? ex: if chip internal temperature is 100℃ , the function will return 100, right?

My setup:

- ARM host processor running 5.10 Linux. 

- Murata 1MW BT/Wi-Fi combo chip (BCM43455) over SDIO

- Wi-Fi firmware: version 7.45.249

- Using linux/hostapd patch sets from "cypress-fmac-v5.10.9-2022_0511"

The issue:

After removing the brcmfmac kernel module, Bluetooth performs very poorly (drops active connections, scan no longer detects devices, sco audio is extremely crackly if the connection does not drop, etc.). This is only observed if Wi-Fi was associated to an AP within 3 seconds of kernel module removal. Re-inserting the module always corrects the issue. 

Example steps to reproduce the issue:

- Start with brcmfmac modules loaded and associated to an AP, then run the following in a script:

ifdown wlan0

modprobe -r brcmfmac

- Bluetooth performs poorly

Then, I ran the following test:

- Start with brcmfmac modules loaded and associated to an AP, then run the following in a script:

wpa_cli disconnect

sleep 3

ifdown wlan0

modprobe -r brcmfmac

- Bluetooth functions normally.

Once I realized a 3 second delay after disconnect prevented the issue, I investigated to see how late in the module removal the delay could be placed before the issue began to occur again. I tried moving the delay into the kernel module itself and found that as long as the 3 second delay is put before the call to brcm_chip_set_passive() made in brcmf_sdio_remove(), then the issue is avoided. If I place it after that call, then I experience the poor Bluetooth performance. 

It seems like the module is left in a state where Bluetooth is in low priority.  Perhaps the module is still attempting to disassociate with the network when the chip is placed in passive mode? I am trying to understand what is happening so that I can avoid this issue properly, rather than inserting a long delay and hoping it is always sufficient. 

Any insight as to what is happening would be greatly appreciated. It is difficult to find information on the BT/Wi-Fi coexistence mechanism used by this chip. 

Thank you,

Goodmorning,

I took over a PsoC6 project from an ex colleague and I simply need to run it on the board (Psoc6 WiFi-BT Pioneer Kit). I must say I have zero experience with embedded development, but I only need to run the latest version of our code. My colleague left some notes, but after I follow successfully the first steps of building the project and pressing the Debug button I get the error "Error: unable to find a matching CMSIS-DAP device". The board is, of course, connected. 

I am feel bad for asking for help for a silly issue like this one, but I also don't want to waste more time trying to fix something I have absolutely no knowledge of.

Thank you

Stefano Bider

Hi,

What is the first device that supports LE-LR (Coded PHY) as Infineon? Will it be the CYW20829?

https://www.infineon.com/cms/en/product/promopages/airoc20829/

Are there any plans for a CYBT module with CYW20829?
What is the MP schedule for each IC and module of the earliest device?

Best Regards,

Hello everybody,

I am trying to use brcmfmac for wifi/Bluetooth combo chip Cypress CYW89359(chip id 4359). Till now, I use the bcmdhd driver provided by U-Blox.

To load the bcmdhd driver, currently I use these parameters (in /etc/modprobe.d/jody-w1-driver-sdio.conf):

options jody_w1_sdio firmware_path=/lib/firmware/brcm/jody-w1-sdio/fw_bcmdhd_RSDB.bin nvram_path=/lib/firmware/brcm/jody-w1-sdio/jody-w163-04a.nvram clm_path=/lib/firmware/brcm/jody-w1-sdio/4359b1.clm_blob

To build the new brcmfmac driver, I followed these instructions:

https://github.com/Infineon/ifx-linux-wireless/

Unfortunately, I fail to bring up a working wlan0 device!

• In the package, v5.4.18 there is a brcmfmac4359-sdio.bin firmware file under.
  • cypress-fmac-v5.4.18/firmware/
• In the package, cypress-fmac-v5.10.9-2021, there is no “..4359-sdio..” anymore.
  
  • All files were renamed to cypress-fmac.. under cypress-fmac-v5.10.9-2021/firmware/

I would have expected a file to exist there, as under point 18 in “release notes”, support for my chip was added:

https://github.com/Infineon/ifx-linux-wireless/blob/master/RELEASE.md

v5.10.9-2022_0511: brcmfmac: add support for BCM4359 SDIO chipset [v5.6-rc1]

But in the same release, there was no firmware file for 4359 available any more.

After a long search, I found this: So CYW/BCM89359 is not (anymore?) supported?:

https://de.osdn.net/projects/immortalwrt/scm/git/immortalwrt/commits/52de8bf86e616de1b86ec2ab5e874029339adb16

“cypress firmware: drop several packages

1. Drop package: cypress-firmware-4359-pcie
   This binary is no longer provided and there are not many details what
   happened.
2. Drop package: cypress-firmware-4359-sdio
   This binary is no longer provided, but in this case, to compare it with
   PCIe package mention as first, there was added
   support in Linux-firmware [1], but no sign of firmware file.
3. Drop package: cypress-firmware-89459-pcie [2]
   According to Infineon: "CYW89459 is an automotive Wi-Fi chip which is not
   supported in the broad market community."

So my question: Is CYW89359 not supported (anymore)?

Even when I had the 4359-sdio.bin firmware file, I still needed to get a 4359-sdio.txt file. The driver was loaded then and a wlan0 device appeared, but unfortunately, I get this error message:

brcmf_fil_cmd_data Firmware error: BCME_UNSUPPORTED (-23)

I found this thread, but it is about bcm4339 and not bcm4359:

https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/BCM4339-Moving-from-bcmdhd-to-brcmfmac/m-p/123250

Best regards,

Michael

Hello!

We have recently purchased a few Wifi+BT M.2 modules  (with Infineon CYW43439, CYW4373E and CYW43012 controllers, all with SDIO host interface) and are in the process of integrating these modules on IMX's i.MX8ULP-CS EVK with linux kernel version 5.10.104 (and soon 5.15.x).

We have some questions and would appreciate any help that you folks could provide in guiding us in the right direction.

What we have done so far:
=========================

1. Begin with Infineon's march update for the 'brcmfmac' driver shipped (as an 'in-tree' driver) in the linux 5.x kernel sources.
- Update name: cypress-fmac-v5.10.9-2022_0331.zip
- Location: https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/Cypress-Linux-WiFi-Driver-Release-FMAC-2022-03-31/td-p/342879

2. Apply the contained patches to the 'in-tree' brcmfmac driver (in the linux 5.10.104 kernel) per instructions in the README file contained in the above mentioned update package.

3. Acquire NVRAM settings files from the murata github repo @ https://github.com/murata-wireless/cyw-fmac-nvram ('master' branch). The above referred Infineon update did not provide these files.

4. Use applicable firmware binaries provided in the Infineon update.

4. Ensure that the (now patched) in-tree brcmfmac driver:
- detects all 3 Infineon controllers correctly,
- loads the matching firmware and nvram settings
- exposes a functioning 'mlan0' interface.

5. Ensure successful access point connectivity, along with subsequent basic network connectivity (ssh, scp etc.) tests.

Our questions:
==============

1. Under what licence (OSS or otherwise) are these these patches provided under? The 'cypress-patches' sub directory in the update package does not contain this information.  The COPYING file in that directory does mention the linux kernel licence, so is it safe to assume that same license applies to the patches as well?

2. These patches produce patching errors when applied to a 5.15.x kernel (5.15.47 in our case).  Is there an ETA when these patches will be ported to the 5.15.x kernel?

3. Are we correct in our approach in using the in-tree brcmfmac driver along the murata supplied NVRAM settings file (instead of the 'fmac' driver provided by murata)?

2. Are we correct in using the Infineon supplied firmware binaries or should we be using the ones from murata @ https://github.com/murata-wireless/cyw-fmac-fw ('master' branch)?

3. Are we correct in using the murata supplied NVRAM settings files for the Infineon modules? If not, where should we get these NVRAM settings files?

We are on a tight schedule and would be grateful for any help you folks could provide.

Hi Sir/ Madam,

I'm working on EMUX in RTOS project on XMC 4200. I am using queue request source for channel 0 and channel 6 for both groups and these channels are configured as master slave.  Other channels in group 1(channel 3, channel 5, channel 4, channel 7 and channel 1) are configured as scan request source. Emux is connected in channel 1 of Group 1. Also using Sequence Mode for EMUX.

Queue request source is triggered using CCU80.SR3(100 us ISR) and scan request source is triggered using CCU40.SR3(100 us ISR).  I am using EMUX1 configuration because am just using 4*1 emux. GPIO pins P2.14 and P2.15 are congigured as EMUX output pins (Alt1). The output of these pins are changing automatically (00b,01b,10b,11b) when I am using CCU80_2_IRQHandler. Evenif I am reading the EMUX inside the ISR(CCU80_2_IRQHandler) or inside the RTOS task( I'm using 100ms RTOS task) it is working fine. But if I am disabling the CCU80_2_IRQHandler the output lines for EMUX is not changing. It is just remaining as one selected line((eg: just 11b) So I will just get one result corresponding to selected line 11b).  

I'm using CCU8 here coz I am using SV-PWM. What would be the reason for select lines for EMUX from MCU is not changing and remaining standstill.  Expecting the reply as soon as possible,

Regards

Ajin A.

Hello everyone, 

I want to know the meaning of magnitude [dB] in the frequency domain in the Radar GUI.

The meaning of "dB" is relative. I want to know what 0 dB means.

Thank you very much!

Best regards