I am using the hardware module 1LD 43438 with Wiced v6.4.
I meet a new issue with the http_client lib (the 1st one on this ticket, currently st...
I am using the hardware module 1LD 43438 with Wiced v6.4.
I meet a new issue with the http_client lib (the 1st one on this ticket, currently still have no answer). The lib can be found here : ".../libraries/protocols/HTTP_clent/http_client.c". I also put the files enclosed.
The communication is done with HTTP request to a server on which I am downloading a .elf file for an OTA update. This file is downloaded by chunk of 1024 bytes.
HTTP request sent to the server:
HTTP response received from the server:
Date: Fri, 30 Jul 2021 12:57:16 GMT
Content-Range: bytes 362496-363519/441816
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Sec-WebSocket-Version: 13HTTP/1.1 101 Switching Protocols
HTTP/1.1 404 Not Found258EAFA5-E914-47DA-95CA-C5AB0DC85B11HTTP/1.0Unable to handle fragmented packetsHTTP/* * *
*Content-LengthTransfer-Encoding: chunkedWrong MAX_FRAGMENT_LENGTH value Unable to set TLS extensionƒH‹HH”H™HH¤HªHHTTP/2OPTIONSGETHEADPOSTPUTDELETETRACECONNECTmalloc_mutexsystem monitorCouldn't create system monitor thread; err = %d
app threadEvent flagsworker queueworker threadStarted ThreadX v5.8Failed to create WICED_HARDWARE_IO_WORKER_THREADFailed to create WICED_NETWORKING_WORKER_THREADbsscfg:event_msgsbsscfg:event_msgs_ext0@ Could not initialize wifi platform****************************************************
** ERROR: WLAN: could not download clm_blob file
** FATAL ERROR: system unusable, CLM blob file not found or corrupted.
****************************************************bus:txglomCould not turn o
If you have a look on the lib http_client.c, the function "deferred_receive_handler" is responsible to provide the http response from the lib to the application. at the line 511, the function try to detect if the header contains the key-word "Transfer-Encoding: chunked". If founded, the response is not managed as this case is not implemented in the lib. It should not be an issue as the server does not answer me with this kind of encoding.
However, the lib seems to looking for this keyword in the entire http response "fragment_available_data_length" (which is the header + the payload) instead of looking for only in the payload.
In my case, the file which I am trying to download, contains the string sequence in ascii format "Transfer-Encoding: chunked". Even if this string is contained in the payload, and not in the header, the lib detect it and the App is not able to process the payload as it is blocked by the lib (enter in the line 513 with the //TODO comment).
=> Could you explain why the lib is looking for the keyword in the entire header+payload data instead of in the header only ? Or is it a bug ?
=> how to handle this issue ?
I think you can easily reproduce this issue with any platform, using the exemple from Cypress Academy WW101 : CypressAcademy_WW101_Files-master\Projects\ww101key\07c\09_aws_get.
If needed for your test, I can share the link to download the .elf file in private message.
According to the datasheet, the CYW4343W has a WLAN unit and Bluetooth unit, both having an ARM CM3 processor, RAM and ROM on-chip memory. Also accor...
According to the datasheet, the CYW4343W has a WLAN unit and Bluetooth unit, both having an ARM CM3 processor, RAM and ROM on-chip memory. Also according to the datasheet:
"External patches may be applied to the ROM-based firmware to provide flexibility for bug fixes or feature additions. These patches may be downloaded from the host to the CYW4343W through the UART transports."
However, I can't seem to find any clear documentation on how to apply patches to the ROM-based firmware. Can anyone refer me to any documentation on how this is done?
A bit more context from my end: we have our custom hardware including a Murata 1DX module, which includes the CYW4343W chipset.
I tried to work on the EWD_Sterling evaluation board, and I want to start from the introducer, but I don't know how to install the ios demo ap...
I tried to work on the EWD_Sterling evaluation board, and I want to start from the introducer, but I don't know how to install the ios demo app on my ipad. The step by step only shows the app (wifiintroduce)location, but it didn't tell how to install it, does any one can help? I never install things to ipad from PC. Thank you.
We have a design that use the laird Sterling EWB (cyw4343w + STM32f4x). I was running test on the sterling laird ewb dev kit via USB (FTDI chip) ...
We have a design that use the laird Sterling EWB (cyw4343w + STM32f4x). I was running test on the sterling laird ewb dev kit via USB (FTDI chip) and everything works fine. Now we are trying to use the JTAG connector with our JLINK segger and we are not able to program the board (our board and the dev kit that as a Jtag connector header).
"**** 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. ****" Downloading DCT ...
Here's what we have done so far :
Change the Jlink driver for the usblibK (220.127.116.11 and 18.104.22.168 try both)
Add reset_config trst_and_srst srst_push_pull to the jlink.cfg file
Change JTAG ?= CYW9WCD1EVAL1 for JTAG ?= jlink.
Our make target look like : "app folder"."app-name"-LAIRD_EWB JTAG=jlink download run.
We try every combination of everything listed but we always add the same result.
In the openocd_log.txt, we got this error (attached files) :
Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc.
Any help would be appreciated, we are running out of solutions here,
Upon this condition, the devB sends a query packet to the group and the devA receives it. Then, the devA makes a reply packet and send to the same group, but the devB never receives it. Wireshark has no packet dump for the devA reply packet, either.
I put some debug message at the function wwd_thread_send_one_packet() in WWD/internal/wwd_thread.c and make sure the packet transfer to the WiFi chip done well as expected.
Here is my question that is any reason the WiFi chip doesn't send a multicast packet out to the network?
(added: it seems to be none of multicast transmit packets actually going out to the network. The call wwd_wifi_get_counters( STA, &counters ) returns counters.txmulti unchanged at all.)
I succeed to communicate through SDIO with the module, flash the module without any error but I've the error
/* 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.
WPRINT_WWD_ERROR(("Timeout while waiting for high throughput clock\n"));
/*@-unreachable@*/ /* Reachable after hitting assert */
The value of the register SDIO_CHIP_CLOCK_CSR is 0x64. One time out of 20 it's working and I've the result 0xC0. (Bit 0x80 is set).
With STM32 Connectivity pack, it's working every times. I can't use STM32 Connectivity pack because I need Wi-Fi Direct (P2P)
I used the STM32 to output the clock for LPO. This clock is always on at frequency 32.768kHz.
The SDIO clock frequency is both 5MHz with WICED and with STM32 Connectivity pack.
I downloaded WICED parameters files from Laird and adapt it to my board. (wifi_nvram_image.h, platform.c/h, platform_config.h). I tested the same set of parameters (wifi_nvram_image.h, binaries files) with STM32 Connectivity pack and it's working.
I check every signals with oscilloscope and I didn't see any major differences.
I use WICED 6.2 because STM32H753 MCU is already added. I adapted files for STM32H733.
Wi-Fi connection(to wireless LAN AP) is lost immediately after 11 hours past with WPA3-SAE. We think it was caused due to Wi-Fi module is down. It's not disconnected by wireless AP. And we have already tried other wireless LAN AP from several vendors, and we confirmed that the same issue was reproduced in every case. However, if we choose WPA2-PSK, the issue doesn't happen. Wi-Fi connection is still alive after 11 hours past.