SDIO communication with 4343W

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

cross mob
ErSt_4460741
Level 3
Level 3
First like received First like given

I am facing issues with the SDIO communication between our host processor STM32F412RGT6 and the CYW4343W.

The wifi chip is from Murata, type 1DX. See link https://wireless.murata.com/type-1dx.html .

When wiced_init() is called, the wiced platform gets initialized. As soon as line 306 of wwd_management.c gets called the

WPRINT_WWD_ERROR(("Could not set Country code\n"));

country code could not be set. As far as I know it is (one of the) first times the WiFi chip is actually requested for answers. Unfortunately the WiFi chip never responds and a TIMEOUT occurs.

I have found the root cause of this issue and I would like to share the solution with you.

In wwd_SDIO.c there is the interrupt handling of SDIO interrupts present. And here and there are some patches, specific for the STM32F412xG processor, like:

#if defined(STM32F412xG)

    if (current_command == SDIO_CMD_5)

        SDIO->ICR = SDIO_ICR_CCRCFAILC;

#endif

.

This fix is a workaround as stated in the errata sheet published by ST. However, this did not fix the communication problem.

I put a probe of an oscilloscope on the OOB line and noticed the line goes high, an interrupt got fired but the line is never pulled low again. So some interrupt was not handled perfectly. In the beginning of the source interrupt SDIO_MASK_SDIOITIE is NOT enabled for this processor. Why???

Anyway, as stated in the reference manual of the STM32F412RG paragraph 27.6.4 SDIO Interrupt there is written how a SDIO handling should be performed. This is not happening according the manual. The manual clearly states:

When SD card interrupt occurs (SDIO_STA[22] bit set), host software follows below steps to handle it.

1. Disable SDIOIT interrupt signaling by clearing SDIOITE bit (SDIO_MASK[22] = ‘0’),

This was not happening, so I put the following line of code at line 543 of function sdio_irq:

#if defined(STM32F412xG)

  if ((intstatus & SDIO_STA_SDIOIT) == SDIO_STA_SDIOIT ) {

SDIO->MASK &= ~SDIO_MASK_SDIOITIE;

  }

#endif

It seemed during debugging that SDIO_MASK_SDIOITIE got ENABLED through enabling of SDIO_MASK_CMDRENDIE and SDIO_MASK_CMDSENTIE. Therefore this interrupt MUST be handled. After the disabling, a handling is required and enabling of the interrupt is needed again (this may happen outside the interrupt handler.

Therefor line 412 of host_platform_sdio_transfer at exit:

    SDIO->MASK = SDIO_MASK_SDIOITIE;

MUST be executed, also for the STM32F412RG. Why was this in #ifndef?

Along with these fixes we were able to have good communication with the WiFi chip and we could start developing the rest using WiFi.

Can you please answer on my questions, marked Bold and Underlined.

I know I am not the only one who had this issue, I just kept digging to find the root cause.

A custom platform board is made with the following options:

  • wiced sdk 6.4
  • CLM blob is placed in internal flash, so with:
  • RESOURCES_LOCATION ?= RESOURCES_IN_DIRECT_RESOURCES

    ifeq ($(RESOURCES_LOCATION), RESOURCES_IN_DIRECT_RESOURCES)

    INTERNAL_MEMORY_RESOURCES = $(ALL_RESOURCES)

    GLOBAL_DEFINES += WWD_DIRECT_RESOURCES

    endif

  • There is an external 25MHz crystal HSE_VALUE=25000000
  • There is an external 32.768kHz crystal on the STM32, and also one on the LPO_IN of the 1DX.
  • The PCB lay-out of the WiFi part is 100% Murata's recommendation
  • SDIO data lines, CMD and CLK, HOST_WAKE have an external 47k pull-up resistor. WL_REG_ON has a 47k pull-down
  • GLOBAL_DEFINES += WICED_DISABLE_WATCHDOG
  • GLOBAL_DEFINES += DBG_WATCHDOG_STM32_TIMER
  • GLOBAL_DEFINES += WICED_DCT_INCLUDE_BT_CONFIG #not sure if this is needed

  • GLOBAL_DEFINES += WICED_DISABLE_MCU_POWERSAVE

  • GLOBAL_DEFINES += GPIO_LED_NOT_SUPPORTED

  • platform.c only declared wiced i/o pins for UART for the debug information visible through Putty (also stdio_config)
  • SDIO config for wifi_control_pins[] and wifi_sdio_pins[]
  • SDIO has nvic priority of 2, sdio dma has 3. uart has 6 and uart dma streams have both 7
  • SYSCLK is set to 100MHz, the SDIO peripheral gets 48MHz.
  • // GPIO pins are used to bootstrap Wi-Fi to SDIO or gSPI mode

    #define WICED_WIFI_USE_GPIO_FOR_BOOTSTRAP_1

    // Wi-Fi GPIO0 pin is used for out-of-band interrupt

    #define WICED_WIFI_OOB_IRQ_GPIO_PIN (0)

    //  Wi-Fi power pin is present

    #define WICED_USE_WIFI_POWER_PIN

    // Wi-Fi power pin is active high

    #define WICED_USE_WIFI_POWER_PIN_ACTIVE_HIGH

    //#define WICED_USE_WIFI_32K_CLOCK_MCO

    // OTA

    //#define PLATFORM_HAS_OTA

1 Solution
ErSt_4460741
Level 3
Level 3
First like received First like given

I don't know yet how to create .patch file with git, so I will post a diff in an image.

sdio1.PNG

sdio2.PNG

View solution in original post

15 Replies
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

Hello:

   I am applying one STMF412 board with 4343w to verify the results you reported.

So your solution is to add below into ISR handle , it that correct ?

#if defined(STM32F412xG) 

  if ((intstatus & SDIO_STA_SDIOIT) == SDIO_STA_SDIOIT ) { 

          SDIO->MASK &= ~SDIO_MASK_SDIOITIE; 

  } 

#endif 

0 Likes

Yes, AND also remove line 412 and 414, so that line 413 SDIO->MASK = SDIO_MASK_SDIOITIE; gets executed as well for the STM32F412xG

0 Likes

sure, thanks a lot.

0 Likes

Would you mind post a patch file (or a diff), so it's easier to understand your changes.

Line number may be different if someone had local changes/fixes in the same file.

0 Likes

Dear ZhengbaoZ_96,

How is your test going? I would like to know the opinion of the WICED development team whether my solution is the correct solution to my problem.

Which board do you use for verification? Did you perform an investigation of the problem on your STMF412 board?

On some other note:

I heard that the original WWD_SDIO.c source worked good in combination with a board from USI type: WM-BN-BM-22. This package contains also a STM32F412. Why does my STM32F412 need my fix and the WN-BN-BM-22 doesn't?

0 Likes

Hello:

  My apply has been approved, I will update the results once I received the boards.

0 Likes

I found the reason, you didn't connect the OOB pin , if you connect the OOB hardware pin, you didn't need to modify any code.

I think this is strange. There is a define that turns off the use of the OOB pin. I do not need the power save feature.

GLOBAL_DEFINES += WICED_DISABLE_MCU_POWERSAVE 

As stated in my opening post, this define is set in my platform.c.

Are you implying that I should NOT use this define? If this define exists it should also work as appropriate!

0 Likes

yes,  if you defined WICED_DISABLE_MCU_POWERSAVE , that means you used in-band SDIO interrupt, so you need to adjust the INT enable progress.

0 Likes

ZhengbaoZ_96 wrote:

yes,  if you defined WICED_DISABLE_MCU_POWERSAVE , that means you used in-band SDIO interrupt, so you need to adjust the INT enable progress.

I don't get your point.

Do you mean if defined WICED_DISABLE_MCU_POWERSAVE, the SDK needs patch to work?

0 Likes

Hello:

yes, from my test that is true .

0 Likes

ZhengbaoZ_96 wrote:

Hello:

yes, from my test that is true .

Does it work after applying ErSt_4460741 's fix?

From this discussion, you even didn't mention if ErSt_4460741 's fix is correct or not.

Can you post the official fix?

Yes, the chip can work well after the patch,  from logic it is reasonable for the INT enable and disable process.

You know, that really needs a lot of time and tests ,and it is ST mcu INT setting ,  I will do enough tests before the confirm.

0 Likes

hello:

just received my board with STM32F412VEH6 + 4343w ,  Strangely,  it will work well with default setting and your patch together , I will have a debug about the INT mask/enable on F412 mcu.  

ErSt_4460741
Level 3
Level 3
First like received First like given

I don't know yet how to create .patch file with git, so I will post a diff in an image.

sdio1.PNG

sdio2.PNG