- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are using STM32H757-Eval board to integrate CYW4373E (connected via Murata uSD-M2 adapter). The controller and CYW4373E is configured as per the latest STM32 connectivity expansion pack(1.2.0 V).
New Project was created from scratch following the instructions mentioned under section 7 in the document. For the platform/device, we selected "CYW4373_STERLING_LWB5PLUS"(Suppose to be CYW4373E). The WL_REG_ON and WL_HOST_WAKE pins were also configured as per the document. The clock for the SDMMC peripheral was configured to 25Mhz. CYW4373E was configured to work in 1.8V mode and the necessary changes were made referring to STM32 connectivity expansion pack(1.2.0 V) document and as well as to STM32H757 Eval kit.
We took inspiration from wifi_scan example and built our project based on that. We were able to successfully compile and flash the code. The terminal window was able to show the available Wifi networks as intended.
Due to design constrains we wanted to check with 3.3V, so we changed the voltage from 1.8V to 3.3V. The appropriate jumpers on CYW4373E for 3.3V was connected.
The application now fails and throws the following information in console.
when we try to debug the application, we were to observe that the application is repeatedly generating "stm32_cyhal_sdio_irq_handler".
When we tried to debug through step in, we were able to find that the application returns error in the following function
and responds in the terminal as follows. With and without debugging returns different errors in the console.
Did anyone in the community faced similar issue? Kindly enlighten us on what's going wrong upon changing the voltage to 3.3V.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
attached new archive, so just overwrite default files (you do not need to use WLAN_MFG_FIRMWARE MACRO )
Regards,
Nazar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
CYW4373E is a chipset, not a module.
What M.2 module containing the CYW4373E chipset are you using? What jumpers specifically did you change?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The reason for the question is this: the M.2 standard defines the SDIO interface as operating at 1.8V. The only way to operate at 3.3V is if a specific module is designed in such a way to support that. In the general case, using standard hardware, 3.3V SDIO operation is not valid.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your reply @DeRa_4514941 .
we are using 2AE module and it is capable of supporting 3.3V. As per the document the resistor positions were changed to configure for 3.3V, highlighted in the below image.
In the murata uSD adapter board, the following Jumper pin connections were made.
J12 – 2 and 3 position
J13 – 1 and 2 position
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you also change your host design to use a fixed 3.3V SDIO bus voltage?
I've not used any of these boards and am not familiar with them. But this sounds like there is a voltage mismatch somewhere in the path between host and radio. Both the host processor and the radio need to see SDIO bus signal levels at the level they are configured to see them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have checked the voltage levels using a multimeter and oscilloscope, all remain as intended. Is there any change we need to do W.R.T firmware?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Udhayadhithan ,
We have tested and developed only with 1.8V . Running at 3.3V for long time may burn the 4373 chip if not configured properly and its a risk.
Thanks,
Rakesh B G
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rakesh,
Thanks a lot for your reply @Rakesh_BG .
Can the firmware(STM32 connectivity expansion pack) still work for 3.3v? If not, what to change in the code to make it work? Could you please guide us on the same? Your help is much appreciated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Udhayadhithan ,
Could you provide more details what changes was done on STM32H757-Eval to have 3.3V SDIO operation?
What voltage is on CN13.4(uSD VCC)? What frequency do you see on SDIO Clk (CN13.5)?
Thanks,
Nazar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NazarP_56 ,
1. In STM32H757-Eval, ST has provided with a voltage level translator to interface with the SD CARD. We removed this module( IP4856CX25) and bypassed the connections of SDIO lines. The following image represents the connections made.
The Power given to Murata M.2 adapter is given from STM32H757-Eval as per the image below,
This hardware configuration was made to replicate STM32H747 DISCO hardware.
2. CN13.4(uSD VCC) showed 3.3V upon inspection and CN13.5(SDIO Clk) produces a clock of 400KHz during the initialization phase and then switches to 25Mhz(DS Mode). The clock signal was raised to 3.3V as well.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
per https://www.embeddedartists.com/wp-content/uploads/2021/05/2AE_M2_Datasheet.pdf we should have pull-up resistors on sdio line (except CLK).
Could you please check this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As per the 2AE schematics, They have an internal pull-up resistor (10K Ohm) on the SDIO lines except for the clock. Adding an external pull-up resistor will decrease the overall resistance(parallel connection), hence no external pull-up resistor was added. Attaching the 2AE schematic image below for reference.
Please let me know if you need further information.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My understanding is following:
schematics which you showed is reference circuit from
https://eu.mouser.com/datasheet/2/281/1/Murata_LBEE5PK2AE_564-3045187.pdf, additionally there is note (p44):
2AE_M2_Module from Embedded Artists (which uses LBEE5PK2AE) does not have pull-ups and require to use an external.
Am i right? or missed something.
Thanks,
Nazar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NazarP_56 ,
Thanks for the quick response.
As per the note in p44, they wanted to add pull-up resistors externally type 2AE. Then why did they have a schematic with external pull-up resistors outside 2AE in p43? Are we missing anything here? Can you help us !!
Reference from P43 in https://eu.mouser.com/datasheet/2/281/1/Murata_LBEE5PK2AE_564-3045187.pdf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is as reference schematic, which demonstrate how to use Type 2AE (LBEE5PK2AE). It is not schematic which shows what we have inside Type 2AE. Module Vendors (like Embedded Artists) or Customer's design can refer to this schematic during design end module/product.
@Rakesh_BG could you confirm my understanding?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NazarP_56,
While we wait for @Rakesh_BG to reply, we added a 100K ohm pull-up resistor to the SDIO lines(D0,D1,D2,D3,CMD) and we observed a voltage of 3.1V on the SDIO lines.
We are still getting errors while trying to connect and below is the screen shot of error received.
We have one bugging question. Before adding the 100Kohm resistor, we were still able to observe 3.3V on the SDIO lines. Doesn't that mean type 2AE was pulled up?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You'll have to talk to Murata and Embedded Artists to get definitive information on their hardware.
But I think the Murata datasheet is both misleading and incorrect. Yes, pull-ups are required per the SDIO specification. No, the Murata module does not implement pull-ups according to their datasheet. But the CYW4373E chip itself, contained in the Murata module, does have internal pull-ups on the SDIO lines per the CYW4373E datasheet. See Table 23 in section 13.6 of the CYW4373E datasheet.
Thus there should be no need for additional pull-ups either in the EA module, or on the M.2 board containing it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One more point - are you using NVRAM/firmware/CLM from Embedded Artists/Murata? You need to be - some of those files are radio specific especially the NVRAM file.
From your description, it sounds like you are using a firmware/config package for the Sterling LWB5+ module from Laird. While it might appear to work, that isn't a valid configuration. The Sterling LWB5+ package is specifically for the Laird LWB5+ module. Behavior on any other CYW4373E based radio module is undefined.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@DeRa_4514941 Exactly. We felt the same as well. That's why we had clearly mentioned that Sterling LWB5+ was only available in STM32 Connectivity Pack as a configuration. There are no explicit CYW4373E configurations (in the device section). Does this mean that the STM32 Connectivity Pack doesn't support CYW4373E directly?
btw, @DeRa_4514941 thanks a lot for your response.
@NazarP_56 @Rakesh_BG Can you kindly verify this point as well. Your help is much appreciated and thanks a lot for all your response.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nothing supports a radio chipset directly. It isn't possible - the chipsets have various configuration options that must be implemented by the radio hardware designer. You don't buy a CYW4373E chip from Infineon, you buy a radio module from Murata, Laird etc. Those radio modules have been implemented in a particular way, and you must use the software package from that module vendor that is configured and tuned for however that module was implemented.
Some aspects of the software are common, such as the driver and often the firmware. But others, especially the NVRAM file are unique to the module design. The correct NVRAM file and the CLM file are also required to leverage any existing module regulatory certifications.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@DeRa_4514941 Thanks for your response and support, We have contacted murata regarding the NVRAM/CLM support for CYW4373E in 2AE.
@NazarP_56 @Rakesh_BG Hope they can help us very soon.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Udhayadhithan,
1. Yes, Sterling LWB5+ is wrong variant for 2AE M.2 Module.
WHD 2.4 which included in STM32 Connectivity Pack 1.2 does not have NVRAM for 2AE M.2 Module.
I see Murata provides set of FW/CLM/Nvram
https://github.com/murata-wireless/cyw-fmac-fw and https://github.com/murata-wireless/cyw-fmac-nvram Please use this variant.
2. I filed internal ticket to update device selection to have possibility to select custom nvram/device.
Regards.
Nazar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @NazarP_56,
Thank you for your response. We came across the NVRAM file (link) from the STM32 expansion pack, which is a .h file.
Could you kindly help us with converting this cyfmac4373-sdio.2AE.txt to the appropriate header file required by the project?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you @NazarP_56 for your response,
We incorporated the NVRAM,CLM & firmware files provided in the zip to the wifi_scan project. The project got built successfully. Upon executing this code we received the following message in the terminal.
To verify whether the firmware is working, we changed the configuration from 3.3V to 1.8V and checked the terminal. We were able to receive the SSID of the wifi networks available as shown in the image.
When we debugged the code in 3.3V configuration, the program is returning a value of SDMMC_ERROR_CMD_RSP_TIMEOUT from the statement(whd_bus_sdio_protocol.c in line 443) shown below.
We took the following steps to change the NVRAM, CLM and Firmware files
- Added the clm_resources.c(replaced) and cyfmac4373-sdio.2AE.clm_blob.c files in the following folder
wifi_scan\Middlewares\Third_Party\Infineon_Wireless_Connectivity\wifi-host-driver\resources\clm\COMPONENT_4373\COMPONENT_STERLING-LWB5plus
- Added resources.h and cyfmac4373-sdio-2AE.c files in the following folder
wifi_scan\Middlewares\Third_Party\Infineon_Wireless_Connectivity\wifi-host-driver\resources\firmware\COMPONENT_4373
- Added wifi_nvram_image.h file in the following folder
wifi_scan\Middlewares\Third_Party\Infineon_Wireless_Connectivity\wifi-host-driver\resources\nvram\COMPONENT_4373\COMPONENT_STERLING-LWB5plus
- The variables used in the cyfmac4373-sdio-2AE.c(wifi_mfg_firmware_image) and cyfmac4373-sdio.2AE.clm_blob.c(wifi_mfg_firmware_clm_blob) required WLAN_MFG_FIRMWARE to be defined. Hence the macro was defined in the preprocessor.
@NazarP_56 kindly provide us insights for the next course of action
Thanks a lot for your time !!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Udhayadhithan,
Please check with pullup resistors,
per https://community.infineon.com/t5/AIROC-Wi-Fi-and-Wi-Fi-Bluetooth/Application-Fails-when-CYW4373E-is... looks like you passed sdio enumeration stage but failed on CLM image downloading. Now we have proper NVRAM, CLM... so it should work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
WLAN_MFG_FIRMWARE is PREPROCESSOR MACRO defined in wifi_mfg_tester project but in the wifi_scan project there was no WLAN_MFG_FIRMWARE MACRO defined. So are the files cyfmac4373-sdio-2AE.c and cyfmac4373-sdio.2AE.clm_blob.c created for manufacture test purpose only and not to used in the Wifi_Scan project or is it ok if we enable the WLAN_MFG_FIRMWARE MACRO in the wifi_scan project itself?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i need to check converted c files, it is not expected to have wifi_mfg_firmware_image_data and wifi_mfg_firmware_clm_blob_data, it should be without _mfg_.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
attached new archive, so just overwrite default files (you do not need to use WLAN_MFG_FIRMWARE MACRO )
Regards,
Nazar