Wi-Fi Combo Forum Discussions

Hi

I am looking for a module to connect to a USB camera and to stream the video data (or the complete USB protocol?) via network. Some of the modules seem to have Wifi and USB hardware, but how complicated is it to "connect" them to each other? Are there any SDK function you can point me at or even some code samples for something similar?

My intention is to build a head-mounted eye-tracker and I would therefore prefer small and lightweight modules. Do you have any recommendations?

Best

Thomas

While I test AVS in WICED Studio 5.01 using BCM943909WCD1, it fails to start speech request and logs "wiced_audio_init returns 4" as below message.

=============

IPv6 network ready IP: FE80:0000:0000:0000:02A0:50FF:FE7A:89B3

0003 00:00:09.161 Initialize audio PLAYBACK device: ak4954_dac

0004 00:00:09.167 Audio_client: enabling playback support

0005 00:00:09.174 Audio render thread begin

0006 00:00:09.177 Audio client thread begin

0007 00:00:09.181 Begin avs mainloop

0008 00:00:09.185 Connect to host: api.amazon.com, port 443, path /auth/o2/token

0009 00:00:09.192 Attemping DNS lookup for api.amazon.com

0010 00:00:09.347 Using IP address 54.239.29.146

0011 00:00:11.079 Attemping DNS lookup for avs-alexa-na.amazon.com

0012 00:00:11.311 Connecting to 54.239.26.171

0013 00:00:14.283 Establishing downchannel stream...

0014 00:00:14.288 Finished sending downchannel message...

0015 00:00:14.757 Received a header for stream 3, flags 0x04

0016 00:00:14.762 Stream 3 received a response status of 200

0017 00:00:14.768 Sending initial synchronize state...

0018 00:00:20.440 Received a header for stream 5, flags 0x05

0019 00:00:20.445 Stream 5 received a response status of 204

0020 00:00:20.451 Connection to AVS established

0021 00:00:30.347 Starting speech request...

0022 00:00:30.352 wiced_audio_init returns 4

0023 00:00:30.356 Unable to initialize/configure audio RX (4)

0024 00:00:30.361 Unable to start audio RX (4)

0025 00:00:30.365 wiced_audio_init returns 4

0026 00:00:30.369 Unable to initialize/configure audio RX (4)

0027 00:00:30.374 wiced_audio_init returns 4

0028 00:00:30.378 Unable to initialize/configure audio RX (4)

0029 00:00:30.384 wiced_audio_init returns 4

0030 00:00:30.388 Unable to initialize/configure audio RX (4)

0031 00:00:30.393 wiced_audio_init returns 4

0032 00:00:30.397 Unable to initialize/configure audio RX (4)

0033 00:00:30.402 wiced_audio_init returns 4

0034 00:00:30.406 Unable to initialize/configure audio RX (4)

=============

For triggering speech request, I push the button, SW4(PLAY/PAUSE).

What is the cause of this failure and how I can correct it?

How correct wifi exploit in sdk3.7 or others?

Can I simple copy wifi firmware from sdk5 into sdk3.7?

BR

Darius

I found that apps/waf/sflash_write frequently fails when building using download_apps on WICED 5.0.0. Unfortunately no error is displayed on the console when this happens, so you would have to look at the build/openocd_log.txt file to see that the file was not completely written. Oddly I noticed that if a system image file had been successfully written to the exact same location previously and hadn't been changed, the file was still bootable when an error occurred that aborted the sflash write. I ended up erasing the the sflash chip after each test and then the system image was not bootable if the sflash write was aborted on the next test. This meant the sflash was not being corrupted, it just wasn't being completely written.

In order to see that the sflash write operation failed on the console, I made changes to the apps/waf/sflash_write/sflash_write.tcl file and to the tools/makefiles/wiced_apps.mk file. I would have liked to have the build process abort displaying an error message when the TCL script failed. The script was already executing exit -1 commands when it aborted, which in my opinion should have caused the build to fail. I couldn't figure out how to get the build to fail on my Windows 10/WICED 5.0 setup. Instead I got the TCL script to display an error message on the console. When wiced_apps.mk runs the TCL script both stdout and stderr are redirected to the log file, so none of the output shows on the console. The TCL script calls the halt command a lot and it sends output to stderr every time. I couldn't figure out how to redirect that output to stdout, so I redirected all output from the TCL script to stderr except for output regarding an error that aborts the program. I used stdout for that. This is obviously backwards. In wiced_apps.mk I only redirect output stderr output from each call of the TCL script to the log file and output to stdout will show up on the console.

In sflash_write.tcl:

I changed all puts "..." calls to puts stderr "..."

Then before each call to exit -1 I added a puts "Sflash write failed! Please try again!"

In wiced_apps.mk:

I changed each of the rules that calls the TCL script so that only stderr(2) was redirected into the log file.

With,

DOWNLOAD_LOG := >> $(OPENOCD_LOG_FILE)

I changed,

$(DOWNLOAD_LOG) 2>&1

into,

2$(DOWNLOAD_LOG)

Example:

FR_APP_DOWNLOAD:  $(FR_APP_DOWNLOAD_DEPENDENCY)...

     $(call CONV_SLASHES,$(OPENOCD_FULL_NAME)) ... -c "sflash_write_file $(FR_APP)..." -c shutdown $(DOWNLOAD_LOG) 2>&1

became,

FR_APP_DOWNLOAD:  $(FR_APP_DOWNLOAD_DEPENDENCY)...

     $(call CONV_SLASHES,$(OPENOCD_FULL_NAME)) ... -c "sflash_write_file $(FR_APP)..." -c shutdown 2$(DOWNLOAD_LOG)

The ultimate result of carefully examining the communication between the TCL script and the sflash_write.c app that the script loads and runs in RAM was that a minor change could fix most of the problem. Both the app and the TCL script share access to the same block of RAM that is used for passing information back and forth. In sflash_write.c this is called the data_transfer struct. The struct contains a 16KB data array and meta data describing where and how much of the array should be saved to the sflash. All I had to do was add the volatile keyword to the definition of each meta data data_transfer struct attribute in order to fix most of this problem.

In apps/waf/sflash_write/sflash_write.c:

I replaced,

typedef struct

{

    unsigned long size;

    unsigned long sflash_address;

    unsigned long command;

    mfg_spi_flash_result_t result;

    unsigned char          data[__JTAG_FLASH_WRITER_DATA_BUFFER_SIZE__];

} data_transfer_area_t;

with,

typedef struct

{

    volatile unsigned long size;

    volatile unsigned long sflash_address;

    volatile unsigned long command;

    volatile unsigned long result;

    unsigned char          data[__JTAG_FLASH_WRITER_DATA_BUFFER_SIZE__];

} data_transfer_area_t;

The device I was originally working on had a custom Murata MCU and a Winbond sflash chip. Since it was unlikely Cypress or anyone else was likely to get one of those boards I reproduced the problem on an Inventek ISMART Arduino Shield (ISM43340) with a Macronix sflash chip. The change above completely fixed the problem on the ISMART board, but when I went back to our custom board I still saw sflash errors on rare occasions although it seemed to be a lot less frequently.

Does anyone have any ideas I might try on our original configuration that might get the problem to completely go away?