I am using the CYW943907AEVAL1F and am trying to  run the ping_ethernet snip

this is the result

WICED_core Initialized

Initialising NetX_Duo v5.12
Creating Packet pools
Ethernet MAC Address : 58:D5:0A:BF:54:51

ethernet: up
Obtaining IPv4 address via DHCP
starting
Platform CYW943907AEVAL1F initialised
=== EXCEPTION ===
Debug event (e.g. breakpoint)
DFSR : 0x00000000
DFAR : 0x00000000
IFSR : 0x00000002
IFAR : 0x004B4332
CPSR : 0x000001D7
R0 : 0x00000001
R1 : 0x12000000
R2 : 0x00000080

anyone any ideas at all ?

Hi! 
We have encountered an error in the http client library.
The expression in image #1 can cause the request (image #2) to be cleared when there is still data coming from the server.
As we understood this happens when the packet size is the same as the fragment size (response_info->total_remaining_length == fragment_available_data_length).
Is there any solution for this bug from the developers?

image #1

image #2

Hi,

I have to upgrade the code from Wiced 2.3 to Wiced 6.6 in which I used Platform BCM9WCDUSI09.
In platform BCM9WCDUSI09 for WLAN BCM43362A2 is used, which is not available in Wiced 6.6.
Can I used old platform i.e BCM9WCDUSI09 in Wiced 6.6 with lates WLAN firmware 5.90.230.38.
If yes then how should I proceed further.

I am using wiced sdk 6.6.0 and I want know is CYW/BCM 43362 chips supports WPA3 security type?

If yes then at which version of wiced sdk was added support of WPA3 and also wanted to know which WLAN firmware version support WPA3 support for CYW/BCM43362 chip?

Thanks

Kaushal Panchal

I am looking into speeding up the time it takes for my device to connect to an AP. A network packet capture is showing a delay of about 2.2 seconds between the active probe response from my AP, and the device sending the Authentication packet to start the connection process.

My device uses an STM32F412 MCU + CYW4343W Wi-Fi/BLE chip, and application is built using WICED Studio 6.6.1 with ThreadX/NetX Duo.

The application performs a Wi-Fi scan, finds the proper AP, updates the DCT with the appropriate channel, BSSID, security for the AP, and then calls wiced_network_up().

I have added debug to WICED, and narrowed down the delay inside of wwd_wifi_join_specific(). The delay is encompassed in the process of sending the JOIN command to the chip and waiting for it to finish –
Call to wwd_sdpcm_send_iovar( SDPCM_SET, buffer, 0, interface ) (where the buffer points to ext_join_params)...

to...

wwd_wifi_join_wait_for_complete( &join_semaphore, interface ) returning success.

I tried changing the parameters for dwell times (to very small values) and number of probes (to 1) in ext_join_params as they were set to use the default values, but this didn’t seem to change behavior.

I captured a network sniff from my Google Pixel of the same process and saw next to no delay between PROBE and AUTHENTICATE, so the delay doesn't seem to be required.

I don’t see where the PROBE to AUTHENTICATE is controlled anywhere in the WICED SDK, so I am assuming this is somehow baked into the chip/firmware?

Am I missing any type of configuration that would speed this up? Is there anything I can change in the SDK, or is this process controlled by the chip/firmware?

My network sniff can't see what is happening on all the channels. Is it possible that the process of traversing the channels during the active probe is the cause of the delay? Does anyone know if the channel traversal stops once it gets a probe response? In my case, the channel has either been 2 or 3. I can try changing this to a higher number to see if it changes the timing at all.

Hi.

I am trying to use mbedtls library with TLS 1.3 support in WICED studio.

I am looking for the BESL supplicant library source code in order to check the transition from phase1 to phase2. Is that available somewhere?

Thanks