Wi-Fi Combo Forum Discussions

I have a question regarding with STM32F4DIS-WIFI Module(Murata SN8200). I need to connect the RTS\CTS pins to make the handshaking between the module and the Microprocessor board. Any idea about how to do that using the WICED, and how can I download the code on the module or embed it in the firmware?

I'm looking for a programmer who could do some contract work on our product based on the WICED SDK.  We're looking for someone in the US (so we can ship hardware easily).  Message me if interested.  Or also at daniel@sprinkl.io

Thanks!

I have an issue with the OpenOCD running on OS X 10.11.1 (El Capitan). My setup includes a jlink JTAG debugger as well as the Broadcom EVB including the BCM43341 (BCM943341WCD1).

The command that I run under Make Project is the following:

demo.MYPROJECT-BCM943341WCD1-debug JTAG=jlink debug

The result of this command is very similar to some other posts. I do see after the build summary the following error printed three times:

**** OpenOCD failed - ensure you have installed the driver from the drivers directory, and that the debugger is not running **** In Linux this may be due to USB access permissions. In a virtual machine it may be due to USB passthrough settings. Check in the task list that another OpenOCD process is not running. Check that you have the correct target and JTAG device plugged in. ****

If I change the Make Project command as follow: demo.MYPROJECT-BCM943341WCD1-debug JTAG=jlink debug VERBOSE=1

to be able to extract one of the commands that creates the issue. I found the following command:

./tools/OpenOCD//OSX/openocd-all-brcm-libftdi --enable-ftdi -f ./tools/OpenOCD/jlink.cfg -f ./tools/OpenOCD/stm32f4x.cfg -f ./tools/OpenOCD/stm32f4x-flash-app.cfg -c "verify_image_checksum build/demo.MYPROJECT-BCM943341WCD1-debug/binary/demo.MYPROJECT-BCM943341WCD1-debug.stripped.elf" -c shutdown

I ran the same command including: --debug=3 so OpenOCD will add more logs. I found this here:

Info : 253 2158 jlink.c:573 jlink_init(): J-Link JTAG Interface ready

Debug: 254 2158 jlink.c:705 jlink_reset(): trst: 0, srst: 0

Debug: 255 2162 log.c:422 keep_alive(): keep_alive() was not invoked in the 1000ms timelimit (2162). This may cause trouble with GDB connections.

Debug: 257 2163 core.c:1591 adapter_khz_to_speed(): convert khz to interface specific speed value

Debug: 258 2163 core.c:1594 adapter_khz_to_speed(): have interface set up

Debug: 259 2164 core.c:1591 adapter_khz_to_speed(): convert khz to interface specific speed value

Debug: 260 2164 core.c:1594 adapter_khz_to_speed(): have interface set up

Info : 261 2164 core.c:1386 adapter_init(): clock speed 1000 kHz

Debug: 262 2164 openocd.c:137 handle_init_command(): Debug Adapter init complete

Debug: 263 2164 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_transport init

Debug: 264 2164 command.c:145 script_debug(): command - ocd_transport ocd_transport init

Debug: 266 2164 transport.c:240 handle_transport_init(): handle_transport_init

Debug: 267 2164 jlink.c:705 jlink_reset(): trst: 0, srst: 0

Debug: 268 2164 core.c:730 jtag_add_reset(): SRST line released

Debug: 269 2164 core.c:754 jtag_add_reset(): TRST line released

Debug: 270 2164 core.c:328 jtag_call_event_callbacks(): jtag event: TAP reset

Debug: 271 2379 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_jtag_reset 1 1

Debug: 272 2379 command.c:145 script_debug(): command - jtag_reset ocd_jtag_reset 1 1

Error: 274 2379 core.c:676 jtag_add_reset(): BUG: can't assert SRST

Debug: 275 2379 command.c:628 run_command(): Command failed with error code -4

Debug: 276 2379 command.c:628 run_command(): Command failed with error code -4

User : 277 2379 command.c:689 command_run_line(): in procedure 'init' called at file "./tools/OpenOCD/stm32f4x-flash-app.cfg", line 10

in procedure 'ocd_bouncer'

Debug: 278 2379 command.c:628 run_command(): Command failed with error code -4

User : 279 2379 command.c:689 command_run_line():

I will follow the post here (Re: OS X version of WICED SDK 3.1.1 posted ) with an Olimex debugger this time and see if I can get it working. The understanding is that the OpenOCD is conflicting with the native FTDI driver.

Please comment this post if you find a way to get the Jlink running on OS X.

Hi,

We are pushing around 1600 bytes status information from the module (BCM943341) over WiFi to the webSocket server hosted by EC2 every second. Also, the server as part of handshake sends a ping every 10 seconds, to which the module responds with a pong.

We have a 130 bytes command that is sent by the server to the web socket client on the module. This can arrive any time. However, we have observed that this message is sometimes delayed and many a time, it is just not received, even though the server gets an ACK for every such message sent.

I wish to know:

(1) do we share tx/rx buffers at the lower layer of tcp socket send/recv?

(2) what is the min/max tx/rx messages that can be sent reliably with moderate to lower latency ~ 1second?

This is all without TLS.

Thanks!

We are using a murata SN8000 module connected via SDIO operating with 48 Mhz to a Cortex-M3 LPC1837.

We are using a WWD ported from the SDK 3.1.2 (including matching patch from murata).

We are using a custom PCB with SPI Flash, SDRAM, MCU and SN8000.

The MCU is operating at 180 MHz.

We are using an older version of FreeRTOS and LWIP (not taken from the SDK).

The SDIO interrupt has the highest interrupt priority.

The WWD task has the highest task priority.

There should be no long interrupt processing during the test.

During synthetic tests we experience reproducible WLAN scan timeouts.

Our test case repeatedly starts a Wireless Access Point, performs a WLAN scan and closes the AP after some seconds.

To perform a WLAN scan our code uses wwd_wifi_scan() and waits up to 10 seconds until the scan callback gets called with the status WICED_SCAN_COMPLETED_SUCCESSFULLY.

Usually the scan callback gets called with status WICED_SCAN_COMPLETED_SUCCESSFULLY after 3 or 4 seconds.

However when a remote WLAN host sends data (e.g. lots of UDP datagrams) to the WLAN module during the scan sometimes WICED_SCAN_COMPLETED_SUCCESSFULLY does not occur within 10 seconds.

In this case our code aborts the WLAN scan with wwd_wifi_abort_scan() which then always returns WWD_TIMEOUT.

Even all following IOCTLs return with WWD_TIMEOUT.

No further communication with the WLAN module is possible until a power cycle is performed.

We've instrumented the WWD code to track the event messages that we receive from the WLAN module. Normally a scan results in lots of events with type WLC_E_ESCAN_RESULT and status WLC_E_STATUS_PARTIAL followed by one last event with status WICED_SCAN_COMPLETED_SUCCESSFULLY. There are a few occasions where a scan terminated with WLC_E_STATUS_ABORT, but this seems to be handled without errors. During all the errors we observed the usual amount of WLC_E_STATUS_PARTIAL events but never received a WICED_SCAN_COMPLETED_SUCCESSFULLY event.

Are there any known issues that could result in the scan not completing?

Are there any known issues that could result in the WLAN module not responding to IOCTLs forever?

Is there any other way to get the WLAN module responding again other than

performing a power cycle?

Best Regards,

Michael Liebert

on behalf of David Natwati