Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
Hi,I am using CYW54907 dev board, WICED SDK 6.6 with default Netx Duo. I want to ask if the wiced sdk has supported for dhcpv6 request, dnsv6 and pin...
I am using CYW54907 dev board, WICED SDK 6.6 with default Netx Duo. I want to ask if the wiced sdk has supported for dhcpv6 request, dnsv6 and pingv6 yet.
Apparently, I don't see any implementation on creating and requesting dhcpv6 on SDK. I did capture packet from the board with the Wireshark, but don't see any dhcpv6 packets. And without dhcpv6 support, i cant get dnsv6 ip address too. I don't even see Router Solicitation packet, Neighbor Solicitation from my board too. Does the sdk currently only generate IPv6 from Router Advertisement packet, and doesn't care about duplicated addresses?
Hi,I am using CYW54907 dev board, WICED SDK 6.6. My board is placed in a mix 2.4GHz, 5GHz network, 2 network has different SSID.Normally, I can connec...
Hi, I am using CYW54907 dev board, WICED SDK 6.6. My board is placed in a mix 2.4GHz, 5GHz network, 2 network has different SSID.
Normally, I can connect to 2.4GHz network and 5GHz network well. But sometimes I cant connect 2.4GHz network or even if I connect the network successfully, I cant get the ip address. I did use a phone hotspot and place the hotspot near my board, but it still can't connect. The issue lasts for 1-2 days.
I don't store ssid and password on default_wifi_config_dct.h or on dct field, I join network using wiced_join_ap_specific(). Strangely enough, if I load scan example, put my network info in default_wifi_config_dtc.h, let it autoconnect via wiced_init(), and constantly press reset button, it can recover. I don't see this case with 5GHz network.
What is the problem with my board and how can i troubleshoot it? I had some fellows who connect to 2.4GHz smoothly, but their environment doesn't have 5GHz network, so I wonder if it's because of my dev board hardware or the mixed 2.4GHz and 5GHz network has some unwanted effects on joining network.
I Just downloaded &installedBM-Windows-WICED-Studio-22.214.171.124-IDE-Installer.zip.
As described in document CY8CKIT-062-WiFi-BT PSoC 6 WiFi-BT Pioneer Kit...
I Just downloaded &installed BM-Windows-WICED-Studio-126.96.36.199-IDE-Installer.zip.
As described in document CY8CKIT-062-WiFi-BT PSoC 6 WiFi-BT Pioneer Kit Guide.pdf
create the following make target: snip.scan-CY8CKIT_062 download_apps download run
WIKED reported 2 errors:
09:53:26 **** Build of configuration Default for project 43xxx_Wi-Fi **** "C:\\Users\\leo\\Documents\\WICED-Studio-6.6\\43xxx_Wi-Fi\\make.exe" snip.scan-CY8CKIT_062 download_apps download run MAKEFILE MAKECMDGOALS=snip.scan-CY8CKIT_062 download_apps download run OTA2_SUPPORT is disabled Making config file for first time tools/makefiles/wiced_config.mk:256: platforms//.mk: No such file or directory tools/makefiles/wiced_config.mk:269: *** Unknown component: CY8CKIT_062. Stop. make: *** No rule to make target 'build/snip.scan-CY8CKIT_062/config.mk', needed by 'main_app'. Stop.
Hello,I met an issue with the lib http and http_client with the function which get the Http answer received after sending a HTTP GET request:
Hello, I met an issue with the lib http and http_client with the function which get the Http answer received after sending a HTTP GET request:
The function callback "deferred_receive_handler" (in /libraries/protocols/HTTP_clent/http_client.c): manage the copy of received TCP data into buffers. One buffer for the header part, and another for the payload. The function detect the separation of the header and the payload with a double "\r\n" sequence. Copy the part before into the header buffer, and the part after into the payload buffer. The double caracters "\r\n" is not saved in the header neither payload buffer.
The function "http_parse_header" (in /libraries/protocols/HTTP_clent/http.c): it parse the keyword of the header by detecting the characters "\r\n". => So, the last keyword of the header is never detected has the buffer is not terminated by the "\r\n" (as removed by the deferred_receive_handler function).
Concretely, if I am looking for a keyword of the header which is positionned at the last keyword, it is never detected! And unfortunately, the keyword order is managed by the server and I can't modify it.
It is a known issue ? is there is patch of something for that ? I can modify the lib function to avoid that but I am surprised that nobody meet this issue before. In addition, I am very surprised as this method is the recommanded usage, found in the exemple Cypress Academy WW101 (CypressAcademy_WW101_Files-master\Projects\ww101key\07c\09_aws_get).
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 (inc...
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 cases when the WLAN module stops accepting SDPCM bus data.
Our test case connects to a WLAN access point and performs several TCP communication scenarios (repeatedly connect to a remote host, transfer many data to remote host, etc) for about 30 minutes.
For a last test step the remote host is configured to drop all incoming network data. The last test step tries 100 times to establish a TCP connection to the remote host with a timeout of 1 second each, which are intended to fail (timeout after 1 second) because the remote host drops all TCP SYN segments.
Afterwards the "drop all incoming network data" is disabled on the remote host and our code performs a TCP connect to the remote host.
Usually this test case performs successfully. However in about 1 out of 10 test runs, the WLAN module stops sending data to the remote host in the middle of the 100 TCP connect loops. We can see the TCP SYN segments every second until suddenly (varying, after 50-90 seconds) the module stops sending them.
Further analysis shows that the WWD driver runs out of bus data credits.