Still no progress. I use SPI bus for now, but it would be great to be able to use SDIO bus, as it has better throughput. It is weird because firmware downloads successfully during bus init and everything breaks on the first use of SDPCM protocol (wiced_management_wifi_on() function), console prints "Could not turn on APSTA" and "Could not set AMPDU parameters" because error 2 (timeout).
Have you hooked up the out-of-band interrupt pin?
This is probably the wlan GPIO0 pin, so you need to ensure that the following functions operate on the correct pins:
Does this help you with SDIO?
Hi, I have the same problem but with Murata ZX, connect with SDIO to STM32F205RG, every pins were connect properly (SDIO, interrupt, reset).
Wiced Version: 2.4.1
Platform BCM943362WCD4 initialised
Started ThreadX v5.5
Initialising NetX_Duo v5.6
Creating Packet pools
Wcd:> Sending pkt 0x20002798
Could not turn on APSTA
Could not set AMPDU parameters
WWD SDIO interface initialised
WLAN MAC Address : 00:00:00:00:7D:DF
WLAN Firmware :
This may have to do with the SN8000 interface and the what the discovery board uses as IO interrupt. Murata can potentially help here. By default we use GPIO0/1 from the WLAN as the bus interrupt.
There is an SDIO ribbon cable that needs to be connected before it will work. Can you describe how you have these signals connected to your board? This is where the GPIO0/1 pins are which gangi was referring to.
I tied SLEEP_CLK to ground and configured SDK to internal sleep clock and now have message "Error while waiting for high throughput clock". Then I updated WICED SDK to 3.0.1 and the same message. SPI still working perfectly. In 3.0.1 version there is a comment in source code above this message:
/* If your system times out here, it means that the WLAN firmware is not booting.
* Check that your WLAN chip matches the 'wifi_image.c' being built - in GNU toolchain, $(CHIP)
* makefile variable must be correct.
but i checked WLAN chip version and it is ok.
Hello - Any luck here?
Still no luck. I am using SPI since throughput offered by SDIO isn't necessary for now in project, but it will be in the future.
I know this thread has not been active for some time, but I'm interested to hear if anybody has made any progress. I'm having the same problem using a STM32F429 and a SN8000 on the SDIO bus.
It's fun to see that this question has been marked "probably solved" !
I have the same problem, apparently the trace "Wcd:> Sending pkt .." breaks the SDPCM protocol (are there any doc available?), probably introducing extra delays. When I remove the trace everything goes fine. Not easy to debug for new platform ports.
If there are not wiring problem!
Try reduce SDIO clock , if your SDIO interface are connected by wired !
Try from lower speed, For example, 1MHz or 400KHz.
Jone, thank you for your answer.
Is this likely that there were wiring problems when the trace is disabled and that everything is working fine ? I'll try anyway your suggestion to reduce the SDIO clock. BTW I am running SN8000X SDK (with STM32F2 on board) and compiled test.console with ThreadX + NetXDuo.
Note that the trace appears late in the initialization process, at least after successful firmware D/L (which is always successful trace being enabled or not).
At the moment the offending trace is show, there are multiple threads competing for SDIO access (SDPCM thread and late init), all protected using mutexes. APSTA and AMPDU init fail when trace is enabled.