What is the Card Initialization Flow (SDIO) for Cyw4343w and WHD driver?

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

cross mob
sofu_4755251
Level 1
Level 1
First like given

Hallo,

The following is our developmenet environment:

Hardware:

Board: STM32F769 Discovery

WiFi Module: Murata-1DX (CYW4343w)

Software:

IDE: Eclipse + CubeMX

WiFi Driver: WHD (Wi-Fi Host Driver (WHD): Main Page)

The Problem:

Command response timeout for both CMD3 and CMD52 (have not tried other commands).

My diagnosis at the moment is that the SDIO card is not properly initialized because the codes generated by CubeMX sends CMD0, CMD8, CMD55, then ACMD41. It can initialize a memory card but not the SDIO card. E.g, the CMD5 it not sent to the SDIO card.

I did not find the implementation of the Init Sequence in WHD. but I have found in the WWD the host_platform_sdio_enumerate ()  and also the initialization flow in the SDIO spec. The sequence in the flow seems much more complicated than the SDIO enumeration in WWD. My question is which one I should use as reference for implementation?  In below, I will post both the flow in WWD and in Specs.

Init flow in WWD  (CMD0 => CMD5 =>CMD3 => CMD7)

wwd_result_t host_platform_sdio_enumerate( void )

{

    wwd_result_t result;

    uint32_t     loop_count = 0;

    uint32_t     data = 0;


    do

    {

        /* Send CMD0 to set it to idle state */

        host_platform_sdio_transfer( BUS_WRITE, SDIO_CMD_0, SDIO_BYTE_MODE, SDIO_1B_BLOCK, 0, 0, 0, NO_RESPONSE, NULL );


        /* CMD5. */

        host_platform_sdio_transfer( BUS_READ, SDIO_CMD_5, SDIO_BYTE_MODE, SDIO_1B_BLOCK, 0, 0, 0, NO_RESPONSE, NULL );


        /* Send CMD3 to get RCA. */

        result = host_platform_sdio_transfer( BUS_READ, SDIO_CMD_3, SDIO_BYTE_MODE, SDIO_1B_BLOCK, 0, 0, 0, RESPONSE_NEEDED, &data );

        loop_count++;

        if ( loop_count >= (uint32_t) SDIO_ENUMERATION_TIMEOUT_MS )

        {

            return WWD_TIMEOUT;

        }

    } while ( ( result != WWD_SUCCESS ) && ( host_rtos_delay_milliseconds( (uint32_t) 1 ), ( 1 == 1 ) ) );

    /* If you're stuck here, check the platform matches your hardware */


    /* Send CMD7 with the returned RCA to select the card */

    host_platform_sdio_transfer( BUS_WRITE, SDIO_CMD_7, SDIO_BYTE_MODE, SDIO_1B_BLOCK, data, 0, 0, RESPONSE_NEEDED, NULL );


    return WWD_SUCCESS;

}

Init flow in SDIO specification

card_initialization_flow.pngcard_initialization_flow_1.png

0 Likes
1 Solution
Murali_R
Moderator
Moderator
Moderator
250 sign-ins 250 replies posted 100 solutions authored

sofu_4755251 Before we go to the SDIO issue, was the port of WHD to the STM32 and the 4343 onto the Cube successful? I am not so familiar with the CubeMX environment so please do bear with me if I ask a few basic questions.

STM32F469 porting in WICED This blog post talks about porting of STM32 to WICED which used WWD. Now I know that you are using WHD, but since the two are pretty similar, it may add some value and give you some pointers on what maybe going wrong.

Regarding the SDIO spec and the wwd implementation under the host_platform_sdio_enumerate(), as far as I am aware, our implementation is also based on the spec and is reduced and simplified to have the bare minimum to get the chip up and running.

Do let me know if this helps or if you need help regarding something more specific.

Thanks

View solution in original post

0 Likes
3 Replies
Murali_R
Moderator
Moderator
Moderator
250 sign-ins 250 replies posted 100 solutions authored

sofu_4755251 Before we go to the SDIO issue, was the port of WHD to the STM32 and the 4343 onto the Cube successful? I am not so familiar with the CubeMX environment so please do bear with me if I ask a few basic questions.

STM32F469 porting in WICED This blog post talks about porting of STM32 to WICED which used WWD. Now I know that you are using WHD, but since the two are pretty similar, it may add some value and give you some pointers on what maybe going wrong.

Regarding the SDIO spec and the wwd implementation under the host_platform_sdio_enumerate(), as far as I am aware, our implementation is also based on the spec and is reduced and simplified to have the bare minimum to get the chip up and running.

Do let me know if this helps or if you need help regarding something more specific.

Thanks

0 Likes

Thanks for the answer. It is good to know that the init sequence in WWD is enough to bring the chip up and running. So i will keep to this implementation in my project, insteading of the whole FSM in the Specs.

Regarding the porting, I have finished (more or less) the work according to the porting guide from WHD and now tried to have the "first contact" with the module. At the moment, I am stucked in the init sequence. I was able to send CMD0. But after sending CMD5, I got a timeout for receiving the response R4. Maybe it is more related to STM than WHD.  I will come back if I got more concrete questions.

Anyway, in my opinion, the implementation of such init sequence can/should be included in WHD since the underlying SDIO commands are implemented during the porting process. Or at least, the porting guide can mention that what the "user" of the driver must implement this and maybe also how it can be implemented. At the moment, such information are missing on the WHD page.

0 Likes

sofu_4755251 Thank you for the feedback. We will try to get this added in one of the future updates/Collateral.

Thanks

0 Likes