CYW43012 with STM32F412G Discovery board WiFi could not set country code

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

cross mob
CharlesOram
Level 3
Level 3
First like received Welcome!

Hi,

I am trying to get a Murata Type1LV module working with the STM32F412G Discovery board with WICED using the snip.scan application.

I have an Embedded Artists 1LV M.2 Module (with the Murata Type1LV module on it) plugged into an Embedded Artists uSD-M.2 Adapter that is plugged into the SD card slot of the Discovery board. I also have WL_REG_ON and WL_HOST_WAKE connected to a GPIO pin on the STM32F412.

Bluetooth works fine, but WiFi does not complete initialisation and reports "Could not set Country code" after the call to wwd_sdpcm_send_iovar() times out in wwd_management_wifi_on().

It seems that everything works fine up to that point and I can step through the initialisation and see that the SDIO bus is working and SDIO interrupts are happening.

I have tried it with and without WICED_DISABLE_MCU_POWERSAVE and have also tried configuring WWD_PIN_SDIO_OOB_IRQ to connect an STM32F4 GPIO to WL_HOST_WAKE.when WICED_DISABLE_MCU_POWERSAVE is not defined. None of these made any difference.

Initially I could not get it to enumerate the SDIO bus, but after I changed wwd_bus_init() to reset the module properly by turning off and on WL_REG_ON that now works.

I have noticed that there is some code in ww_sdio() that treats the SDIO Interrupt differently for the STM32F412xG, but there are no comments to explain why. There are other posts in this forum that mention this, but they don't come to any conclusions.

With that code in it does get SDIO interrupts up until before the wwd_sdpcm_send_iovar() to set the country code. After wwd_sdpcm_send_iovar() times out the SDIOIT bit in the SDIO STA register is set.

I have tried removing the STM32F412G specific code, but then it gets repeated SDIO interrupts.

The makefile has WLAN_CHIP_REVISION := C0 I I cannot find any information about what revision chip is in the Murata modules.

Can anyone suggest what I could try to get this working?

regards,

Charles

0 Likes
1 Solution

The problem was in the nvram file. It's working now.

I noticed that the nvram file on https://github.com/murata-wireless/cyw-fmac-nvram had these lines:

# muxenab defined to enable OOB IRQ. Level sensitive interrupt via WL_HOST_WAKE line.

muxenab=0x1

and my nvram file didn't have muxenab, so I added this line to wifi_nvram_image.h and it now works

"muxenab=0x1"                                                        "\x00"

Thanks for your help!

View solution in original post

0 Likes
10 Replies
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

Dear Charles,

I have seen this issue to be occurring in the past when OOB pin is not correctly configured; i.e the CYW43012 can't signal the host MCU when a packet is available. Kindly setup and configure the OOB pin correctly in the hardware ( F412 GPIO <--> WL_HOST_WAKE of 1LV) as well as in the platform.c (WWD_PIN_SDIO_OOB_IRQ GPIO pin: PC6 for CY platform BCM94343WWCD2 should be connected to 1LV host_wake).

The different treatment of SDIO interrupts for F412 done inside wwd is because of a chip errata published by ST. I will recommend not to change the WWD side of things otherwise you will get repeated interrupts. When you are enabling WICED_DISABLE_MCU_POWERSAVE in the makefile, you are basically bypassing the OOB interrupt and instead trying to use in-band interrupt for which you would need some other changes and is not recommended from Cypress because of the low-power number.

Also, please check the LPO_IN pin status which is enumerated as WWD_PIN_32K_CLK in platform.c;

Hi,

Thanks for your reply - I think I was on the right track, but haven't got it working yet. I will investigate the OOB interrupt in more detail.

In my application I don't need low power, so can I expect the Cypress WICED driver to work with WICED_DISABLE_MCU_POWERSAVE defined?

Also, do I need to connect WL_DEV_WAKE? I can't find anywhere in the CYW943012EVB_04 or CYW943012P6EVB_01 platform examples where this pin is configured.

The Embedded Artists uSD-M.2 Adapter provides the LPO clock, so I assume that I do not need to generate this from the STM32F412.

regards,

Charles

0 Likes

I've been doing a bit more testing and with WICED_DISABLE_MCU_POWERSAVE not defined, wifi_sdio_pins[WWD_PIN_SDIO_OOB_IRQ] correctly configured and WL_HOST_WAKE connected to the correct MCU pin the wwd_sdpcm_send_iovar() call to set the country code still times out.

I checked that the LPO clock is OK with a 'scope - I can see it on the test pad on the Embedded Artists 1LV M.2 Module.

With a 'scope on WL_HOST_WAKE I can see that it stays low and does not ever go high.

If I disconnect WL_HOST_WAKE (to let the MCU pin float high) while the code is in wwd_sdpcm_send_iovar() and immediately reconnect it then I get OOB interrupts and the set country code succeeds and I get a few scan results printed out on the serial port.

So it looks like the CYW43012 is not controlling WL_HOST_WAKE. Any ideas why?

Thanks for your help.

0 Likes

Have you connected an external 10K Pull up resistor to 1.8V from the WL_HOST_WAKE pin in 1LV module?

It's better to connect the WL_DEV_WAKE to a GPIO of STM32F412 instead of keeping it floating (The pin can be configured internally through NVRAM for very low power WLAN implementation which I guess is not the requirement for your application).

0 Likes

Yes, the uSD to M.2 adapter has a 10k pull-up to 1.8V on WL_HOST_WAKE.

What I meant is that I can simulate the interrupt by briefly disconnecting the WL_HOST_WAKE_3V3 line between the uSD to M.2 adapter and the STM32F412. So that proves that the 1LV module is keeping WL_HOST_WAKE low.

0 Likes

Can you attach the nvram file you are using and also make sure that #define WICED_WIFI_OOB_IRQ_GPIO_PIN  ( 0 ) is present in platform_config.h?

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

My platform setup is modified from CYW943012EVB_04 so I am using the wifi_nvram_image.h from that platform (see attached).

0 Likes

The problem was in the nvram file. It's working now.

I noticed that the nvram file on https://github.com/murata-wireless/cyw-fmac-nvram had these lines:

# muxenab defined to enable OOB IRQ. Level sensitive interrupt via WL_HOST_WAKE line.

muxenab=0x1

and my nvram file didn't have muxenab, so I added this line to wifi_nvram_image.h and it now works

"muxenab=0x1"                                                        "\x00"

Thanks for your help!

0 Likes

One last question...

Are the settings in the nvram file documented anywhere?

0 Likes

Ideally, the nvram file should be provided by the module vendor (in this case Murata Github) based on their testing and HW design. Customers are not supposed to change nvram parameters by themselves since that can impact the RF performance significantly. That being said, a preliminary documentation is available from Cypress. I am mentioning them here:

https://www.cypress.com/documentation/application-notes/an225021-cyw43012-otp-programming-and-nvram-...

Please note that for any changes required in NVRAM, kindly get in touch with your module vendor.