cancel
Showing results for 
Search instead for 
Did you mean: 

Wi-Fi Combo

rzec_3016261
New Contributor II

Hello all,

Situation is:

Hardware:

  • my own (STM32F756 + CYW4343WKUBG)
  • bus used == SDIO

Software:

  • WICED-Studio-6.2-SDK
  • no IDE, just makefiles [ ./make snip.sntp_get_time-MYPLF-FreeRTOS-LwIP download run ]

 
Problem:

I’m stuck at ( SDIO->RESP1 & 0x800 ) in wwd_SDIO.c Why?

Software sequence where it goes wrong:

wwd_bus_protocol.c:628 wwd_result_t wwd_bus_write_backplane_value(

wwd_bus_protocol.c:637 VERIFY_RESULT( wwd_bus_sdio_transfer(

wwd_bus_protocol.c:671 static wwd_result_t wwd_bus_sdio_transfer(

wwd_bus_protocol.c:707 static wwd_result_t wwd_bus_sdio_cmd53(

  wwd_bus_protocol.c:728 result = host_platform_sdio_transfer(

The host_platform_sdio_transfer() is MCU specific, my version is the same as the STM32F4xx MCU version but uses the STM LL library references.

All goes well, except I hit the (SDIO->RESP1 & 0x800) and therefore sdio_transfer_failed = WICED_TRUE;

Now my problem is that I have a not supported platform (STM32F7xx) and new hardware so I would very much have some in-depth understanding of what this error means.

 

I have found this link https://community.cypress.com/message/26491#26491

but it doesn’t seam to relate to my problem since the data used when it hits this problem is 4 bytes long and sits in RAM memory. So no DMA TXUNDERR.


Thanks for any help.

Regards.

0 Likes
1 Solution
rzec_3016261
New Contributor II

OK found the problem.

It was a timing issue. The SDMMC1->FIFO did not get filled fast enough after initializing the SDMMC1 and enabling the DMA.

Got it working.

View solution in original post

13 Replies
RaktimR_11
Moderator
Moderator

Are you using the wwd_sdio.c from STM32F4xx platform? You can try checking the suggestions provided regarding the SDIO interface in STM32F469 porting in WICED to enable the wwd_stats and see whether it is just cmd53 or cmd52 or both are failing. Since it's a new MCU, you are trying to port, you have to correctly write the host_platform_sdio_transfer based on ST documentation and then proceed with all the checks.

0 Likes
rzec_3016261
New Contributor II

Thanks.

Yes I have used the wwd_sdio.c from STM32F4xx as basis for the STM32F7 version.

As far as I can tell cmd52 is working as it should.

wwd_bus_protocol.c: VERIFY_RESULT( host_platform_sdio_enumerate() );

returns without any failure.

I will work through the suggested post again, and incl wwd_stats (did not do that yet).

rzec_3016261
New Contributor II

I have worked through the suggested post and enabled wwd_stats.

Added wwd_print_stats(WICED_FLASE); in wwd_bus_protocol.c (wwd_bus_init function)

    elapsed_time = host_rtos_get_time( );

    result = wwd_bus_sdio_download_firmware( );

    elapsed_time = host_rtos_get_time( ) - elapsed_time;

    host_platform_resource_size( WWD_RESOURCE_WLAN_FIRMWARE, &wifi_firmware_image_size );

    WPRINT_WICED_TEST( ("WLAN FW download size: %lu bytes\n", wifi_firmware_image_size) );

    WPRINT_WICED_TEST( ("WLAN FW download time: %lu ms\n", elapsed_time) );

    wwd_print_stats(WICED_FALSE); /* DEBUG CODE */

    if ( result != WWD_SUCCESS )

    {

        /*  either an error or user abort */

        return result;

    }

( result != WWD_SUCCESS ) == TRUE the code returns here.

This gives me on my console:

     WLAN FW download size: 383110 bytes

     WLAN FW download time: 42 ms

     WWD Stats..

     tx_total:0, rx_total:0, tx_no_mem:0, rx_no_mem:0

     tx_fail:0, no_credit:0, flow_control:0

     Bus Stats..

     cmd52:53, cmd53_read:0, cmd53_write:1

     cmd52_fail:0, cmd53_read_fail:0, cmd53_write_fail:1

     oob_intrs:0, sdio_intrs:47, error_intrs:0, read_aborts:0

If I use the following GLOBAL_DEFINES:

GLOBAL_DEFINES += SDIO_1_BIT

GLOBAL_DEFINES += SLOW_SDIO_CLOCK

the problem persists.

     WLAN FW download size: 383110 bytes

     WLAN FW download time: 42 ms

     WWD Stats..

     tx_total:0, rx_total:0, tx_no_mem:0, rx_no_mem:0

     tx_fail:0, no_credit:0, flow_control:0

     Bus Stats..

     cmd52:51, cmd53_read:0, cmd53_write:1

     cmd52_fail:0, cmd53_read_fail:0, cmd53_write_fail:1

     oob_intrs:0, sdio_intrs:47, error_intrs:0, read_aborts:0

The logic analyser suggests all pins are connected correct:

trace.jpg

I have CLK and CMD.

BTW the CLK is approx 700kHz (very slow)

What I never see is the data line toggle.

Any suggestions, please.

Is there a way to contact a Cypress FAE directly? I need to have this issue resolved quickly, our customer has passed the annoyed state......

Thanks.

0 Likes
rzec_3016261
New Contributor II

Progress???

WLAN FW download size: 383110 bytes

WLAN FW download time: 32 ms

WWD Stats..

tx_total:0, rx_total:0, tx_no_mem:0, rx_no_mem:0

tx_fail:0, no_credit:0, flow_control:0

Bus Stats..

cmd52:53, cmd53_read:0, cmd53_write:2

cmd52_fail:0, cmd53_read_fail:0, cmd53_write_fail:1

oob_intrs:0, sdio_intrs:48, error_intrs:0, read_aborts:0

2 writes, 1 fail.

Don't know why.

0 Likes
RaktimR_11
Moderator
Moderator

Please create a debug build and enable WPRINT_ENABLE_WICED_ERROR macro in wiced_defaults.h and check what is the assert you are hitting. Other option would be to check the content of SDIO (43xxx_Wi-Fi/WICED/platform/MCU/STM32F4xx/WWD/wwd_SDIO.c) in debugger to find out the exact why?

Regarding getting in touch with a FAE, you can contact your local Cypress Sales office and they can get your request prioritized through a FAE.

rzec_3016261
New Contributor II

OK found the problem.

It was a timing issue. The SDMMC1->FIFO did not get filled fast enough after initializing the SDMMC1 and enabling the DMA.

Got it working.

View solution in original post

rad_4757021
New Contributor II

Hi rzec_3016261,

Actually we too have a similar requirement to start work with the customised hardware: STM32F7 + BCM4343 ==> (BLE + WiFi).

Here we are planning to use the WICED SDK.

Since we are at begging, could you please suggest to us or refer any related document to use WICED SDK for STM32F7 pltform.

Thanks in advance for your help.

0 Likes
RaktimR_11
Moderator
Moderator

STM32F469 porting in WICED​ should be of help. But this document is not specific to STM32F7xx but should give you the overall idea.

rad_4757021
New Contributor II

Thank you for quick reply and reference doc.

Do we have to use CubeMX/CubeStudio IDE tool flash STM32 MCU separately or WICED SDK alone sufficient to handle/flash both STM32F7xx + BMC4343?

0 Likes
RaktimR_11
Moderator
Moderator

WICED SDK is sufficient to manage both stm32f7xx + cyw4343w, provided you manage to have a functional port for stm32f7xx in WICED. There is also an existing plan to enable the customers to use CubeMX to program both of devices but it's not yet fully migrated/integrated. If you want to use the second option, please get in touch with your nearest Cypress Sales/Marketing team with the opportunity details and they can help you out.

rad_4757021
New Contributor II

Thank you for the quick support.

0 Likes
sofu_4755251
New Contributor

Hi,

In our project, we are also facing a very similar problem. We have stm32F769 discovery board and try to interface to the muRata 1DX (cyw4343w) module. Minor difference is that we have an already running LWIP for the Ethernet in FreeRTOS. And also, we use the cubeMX and cmake-based projects in Eclipse.

I will first try the porting to F7 following the guidelines. After that, is there any examples in the WICED SDK that I can used to test? 

Could anybody give some guidelines how to proceed in my case? Should I use WICED API or only WWD? At which level I can integrate the codes from WICED into our project?

I personally don't have any experience with WICED, so any suggestions or tips will be really appreciated.

Thanks in advance!

0 Likes
RaktimR_11
Moderator
Moderator

You can use the snip.scan example to test the porting. If you don't want to get into understanding wiced/wwd from scratch, we have a newer wifi-host-driver which works with a CYW4343W: GitHub - cypresssemiconductorco/wifi-host-driver: Embedded Wi-Fi Host Driver that provides a set of ...

Porting guide for WHD: Wi-Fi Host Driver (WHD): Main Page

I am going to close this thread since this is an old one and have limited audience. Instead, if you face any difficulty while either porting the whd to cubeMX or having the stm32f769 support added in wiced sdk with older driver offering known as wwd.

0 Likes