Application Fails when CYW4373E is changed to 3.3V

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Udhayadhithan
Level 2
Level 2
25 sign-ins First like received 10 replies posted

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.

Udhayadhithan_1-1669192663645.png

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

Udhayadhithan_2-1669192922828.png

and responds in the terminal as follows. With and without debugging returns different errors in the console. 

Udhayadhithan_0-1669192585869.png

Did anyone in the community faced similar issue? Kindly enlighten us on what's going wrong upon changing the voltage to 3.3V.

  

0 Likes
1 Solution
lock attach
Attachments are accessible only for community members.

Hi  

attached new archive, so just overwrite default files (you do not need to use WLAN_MFG_FIRMWARE MACRO )


Regards,
Nazar

View solution in original post

0 Likes
30 Replies
Udhayadhithan
Level 2
Level 2
25 sign-ins First like received 10 replies posted

@Rakesh_BG Could you please look at this issue? It would be very helpful. Thanks

0 Likes
DeRa_4514941
Level 2
Level 2
10 replies posted 5 replies posted 100 sign-ins

CYW4373E is a chipset, not a module. 

What M.2 module containing the CYW4373E chipset are you using?  What jumpers specifically did you change?

0 Likes
DeRa_4514941
Level 2
Level 2
10 replies posted 5 replies posted 100 sign-ins

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.

0 Likes
Udhayadhithan
Level 2
Level 2
25 sign-ins First like received 10 replies posted

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.

Udhayadhithan_0-1669874609104.png

In the murata uSD adapter board, the following Jumper pin connections were made.
J12 – 2 and 3 position
J13 – 1 and 2 position

Udhayadhithan_1-1669874672955.png

 

 

0 Likes
DeRa_4514941
Level 2
Level 2
10 replies posted 5 replies posted 100 sign-ins

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.  

0 Likes

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?

0 Likes
Rakesh_BG
Moderator
Moderator
Moderator
50 solutions authored 100 replies posted 100 sign-ins

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

0 Likes

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.

 

0 Likes

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

0 Likes
Udhayadhithan
Level 2
Level 2
25 sign-ins First like received 10 replies posted

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.

 

2022-12-12 19 32 51.jpg

 

The Power given to Murata M.2 adapter is given from STM32H757-Eval as per the image below,

 

Presentation1.png

 

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

 

0 Likes

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

NazarP_56_0-1670961745958.png

Could you please check this?

 

0 Likes

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.

 

2AE.png

 

Please let me know if you need further information.

Thanks

0 Likes

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): 

NazarP_56_1-1671105979987.png

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

0 Likes

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

2AE.png

0 Likes

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.

 could you confirm my understanding?

0 Likes

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.

2022-12-15 19 49 37.jpg

 

 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? 

0 Likes

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.

 

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.

0 Likes

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

0 Likes

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.

0 Likes

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

0 Likes

Hi 

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

0 Likes

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?

0 Likes

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.

Udhayadhithan_0-1671702106875.png

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.

Udhayadhithan_1-1671702288231.png

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.

 

Udhayadhithan_3-1671702692483.png

  

We took the following steps to change the NVRAM, CLM and Firmware files

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

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

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

  1. 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 !!!

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

 

 

0 Likes

@NazarP_56 

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?

0 Likes

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

0 Likes

Thank you @NazarP_56 for clarifying the question. Waiting for the updated package file.

0 Likes
lock attach
Attachments are accessible only for community members.

Hi  

attached new archive, so just overwrite default files (you do not need to use WLAN_MFG_FIRMWARE MACRO )


Regards,
Nazar

0 Likes