- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am trying to connect Murata SN8000 to STM32F4 Discovery kit through SDIO bus. Everything works fine (reading/writing broadcom chip's registers, downloading firmware) until start of communication through SDPCM protocol - wiced_send_iovar() (SDPCM.c) timeouts on wiced_ioctl_sleep semaphore. Wiced thread is running. Here is console dump of snip.udp_transmit-SN8000x-SDIO (all prints enabled):
Starting Wiced v2.4.1
Platform SN8000x initialised
Star▒Starting Wiced v2.4.1
Platform SN8000x initialised
Started FreeRTOS v7.1.0
Initialising LwIP
Wcd:> Sending pkt 0x20004B44
Could not turn on APSTA
Could not set AMPDU parameters
Error 2 while starting WICED!
WWD SDIO interface initialised
WLAN MAC Address : 02:00:00:00:00:00
WLAN Firmware :
It prints the same with ThreadX, so I assume it isn't OS issue. Raw SDIO works, everything works also fine with SPI bus, so it isn't probably hardware issue.
Murata SN8000 module's GPIO0, GPIO1, RST_N, VDD_3V3_EN pins are connected to STM32F4 Discovery kit. SLEEP_CLK is driven by PWM.
I am using Wiced SDK 2.4.1 almost untouched (I modified makefile commands running OpenOCD to connect to st-link)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
host_platform_get_oob_interrupt_pin
wwd_bus_sdio_set_oob_interrupt
host_enable_oob_interrupt
Check values:
WWD_PIN_SDIO_OOB_IRQ
WICED_WIFI_OOB_IRQ_GPIO_PIN
Regards,
Evan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does this help you with SDIO?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 :
Any idea/progress?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello - Any luck here?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What you meaning everything work fine?
Is WiFi could connect to AP and pass data ?
If WiFi work ! You could ignore those two warning message !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you using a SN8000 EVK board? Or is the SN8000 module mounted on a custom PCB ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for confusion, i will try to make it clear. I am using both configurations: SN8000 EVK and custom HW (actually the SN8000 EVK SDCARD module plugged into another SBC).
When using the genuine EVK, and unmodified wiced stuff, all (I only use test.console) compiles and runs perfectly. When I add some debug (changing wiced_defaults.h), enabling WPRINT_WWD_DEBUG traces, it still compiles, but fails at execution (last trace comes from wwd_thread.c):
Starting WICED v3.1.2
Platform SN8000x initialised
Started ThreadX v5.6
Initialising NetX_Duo v5.7_sp1
Creating Packet pools
Wcd:> Sending pkt 0x2000B1D4
opening a GBD session, I observe the following:
^C
Program received signal SIGINT, Interrupt.
platform_power_down_hook (sleep_ms=1879)
at WICED/platform/MCU/STM32F2xx/peripherals/platform_mcu_powersave.c:301
301 }
(gdb) bt
#0 platform_power_down_hook (sleep_ms=1879)
at WICED/platform/MCU/STM32F2xx/peripherals/platform_mcu_powersave.c:301
#1 0x0800fef0 in tx_low_power_enter ()
#2 0x0800fb72 in __tx_ts_wait ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info threads
[New Thread 536961992]
[New Thread 536874232]
[New Thread 536873976]
[New Thread 536873720]
[New Thread 536956944]
Id Target Id Frame
6 Thread 536956944 (WWD : : Ready) 0x0800fbaa in _tx_thread_system_return ()
5 Thread 536873720 (worker thread : : Waiting - Queue) 0x0800fbaa in _tx_thread_system_return ()
4 Thread 536873976 (worker thread : : Waiting - Queue) 0x0800fbaa in _tx_thread_system_return ()
3 Thread 536874232 (system monitor : : Sleeping) 0x0800fbaa in _tx_thread_system_return ()
2 Thread 536961992 (app thread : : Waiting - Semaphore) 0x0800fbaa in _tx_thread_system_return
()
* 1 Thread -1 (Current Execution) platform_power_down_hook (sleep_ms=1879)
at WICED/platform/MCU/STM32F2xx/peripherals/platform_mcu_powersave.c:301
I am not deeply concerned with this issue on EVK, excepted that it shows how enabling trace may lock the application, which is not a good news when you aim to port to a custom hardware. I would love to hear to someone else can reproduce this, so the issue can be reported and luckily someone may fix it.
By the way, I also work with a custom SBC (plus SN8000 SDIO module) and porting WICED to this target becomes more difficult when I can't rely on traces.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I used alot of time when we prototyped our custom PCB. We used a STM32F429 eval. board and connected the SN8000 SDIO PCB. I ended up finding out that only worked when the SN8000 module was plugged into the SN8000 EVK socket. When we moved to our custom PCB the problems disappeared and I expect that many of the problems was caused by the nature of the prototype (long wires, etc.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello again,
We just got the second HW of our custom PCB and at first I was back getting the "Could not turn on APSTA" error, turned out I forgot to move the reset pin for the WLAN module. I was doing some digging and just as you have noticed, enabling the WPRINT_WWD_DEBUG on the makes it fail with the "Could not turn on APSTA" error as well, when the define is not set it boots as expected. This is present on both HW revisions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
please try latest WICED SDK release and check whether the problem still persist.
If you still find the same error please create a new thread.
cypress team will start assisting you.