wiced_ioctl_sleep semaphore timeout

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

cross mob
Anonymous
Not applicable

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)

21 Replies
GregG_16
Employee
Employee
50 sign-ins 25 sign-ins 25 comments on KBA

Jakub Rak

Have you made any progress?  Any other details you have that can help us?

0 Likes
Anonymous
Not applicable

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).

0 Likes
Anonymous
Not applicable

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

0 Likes

Does this help you with SDIO?

0 Likes
Anonymous
Not applicable

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?

0 Likes

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.

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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.

0 Likes

Hello - Any luck here?

0 Likes
Anonymous
Not applicable

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.

0 Likes
Anonymous
Not applicable

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.

0 Likes

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.

0 Likes
Anonymous
Not applicable

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.

0 Likes

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 !

0 Likes

Are you using a SN8000 EVK board? Or is the SN8000 module mounted on a custom PCB ?

0 Likes
Anonymous
Not applicable

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.

0 Likes

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.)

0 Likes

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

0 Likes

Moving to the WICED Wi-Fi Forums​ and adding david_armour

0 Likes
Anonymous
Not applicable

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.

0 Likes