Wi-Fi Combo Forum Discussions

Hi All,

My customer is considering to use 43907 in device which has no user interface. Other chipset vendor had their own implementation for  provisioning a new Wi-Fi device to a WiFi network. Some uses mobile app to broadcast the network credentials from a smartphone, or a tablet, to an un-provisioned Wi-Fi device, and the device sniffer special packets from the air that containing SSID and password of target AP.

I would like to know if Cypress has similar implementation. 

Thanks,

Hi Experts, 

My materials are STM32L4P5 and CYW43438. 
What I can't figure out is that while I build the sample (snip.gpio), I can see the LED on the board blinking. but if I remove the USB type-C(5V), the LED will turn off(still provide 3.3V from a battery).

The purpose that I have to remove the USB type-C is that I have to connect the UART and monitor the output on Teraterm. 

I just wondered  what would be the reason caused for this situation? 

 Thanks! 

Hi 

I use cypress 4343A1 (Laird EWB )

I use OS - Thredex.

When I try to create/init queue by API wiced_rtos_init_queue

I get return code 04 (WICED_ERROR). 

Please let me know what the problem

HarelT

I'm trying to initialize a new sflash chip on an ISM43340. I was able to determine how to add the flash chip and size to the Wiced configuration. However, determining how to initialize the sflash chip took several days of digging.

=== Solution ?? ===
Eventually, the line below was added to initialize the sflash when running the make: snip.sflash_write-.
- Is this the correct change? Is this the correct placement?

../43xxx_Wi-Fi/platforms/ISM43340_M4G_L44/ISM43340_M4G_L44.mk
RESOURCES_LOCATION ?= RESOURCES_IN_WICEDFS

=== Diagnostic History ===
The first attempt was to run snip.ota_fr-ISM43340_M4G_L44 because that's what the documentation suggests to use to flash a new OTA app file. However, that failed because the wiced_apps_common.c / wiced_apps_get_size code isn't designed to detect an uninitialized sflash chip. 

When building the sflash_write, the filesystem.bin file wasn't being generated nor was the sflash being initialized. See below for the missing messages.  It took a couple of days to root cause the problem and find a possible solution. BTW, this sflash init worked fine out of the box for the eval board: CYW943907AEVAL1F, but not for the ISM43340.

===wiced_apps_common.c / wiced_apps_get_size issue ===
The wiced_apps_get_size() code essentially went into a nearly infinite loop when run with the uninitialized sflash chip.  It seems feasible to add a check. The chip being used was (MX25U1633FM2I) apparently factory initialized to all 1s, because the error eventually found in debugging that (wiced_apps_get_size) method was reading all 1s for the app_header.count field. That is, under the assumption that all sflash chips are either factory initialized to all 1s or all zeros.... perhaps a code check would be helpful.

===wiced_apps_common.c / wiced_apps_get_size code suggested change ===

wiced_result_t wiced_apps_get_size( const image_location_t* app_header_location, uint32_t* size ) {
...

   WICED_VERIFY( init_sflash( &sflash_handle, PLATFORM_SFLASH_PERIPHERAL_ID, ...));
    WICED_VERIFY( sflash_read( &sflash_handle, app_header_location->detail.external_fixed.location, .......));
    // code change here suggested checking for 255 or 0, which will be an error 99.999999% of the time
    if (app_header.count > 254 || app_header.count == 0) return ERR_CODE_SFLASH_NOT_INITIALIZED; 

=== The messages below would NOT appear in the make/build log until after adding the make file line as mentioned above
     (RESOURCES_LOCATION ?= RESOURCES_IN_WICEDFS) ==== 

16:20:54.367 -> NO Support Range Erase Command!!
16:21:05.562 -> Waiting for command
16:21:05.562 -> Received command: POST_WRITE_VERIFY WRITE_ERASE_IF_NEEDED
16:21:05.562 -> Destination address: 4096
16:21:05.562 -> Size: 16384
16:21:05.562 -> Initialising serial flash
16:21:05.598 -> Done initialising
16:21:05.598 ->
16:21:05.598 ->
16:21:05.598 -> SFLASH Device ID1 ( 0xc22015)
16:21:05.598 -> SFLASH Size1 ( 0x200000)
16:21:05.598 ->
16:21:05.598 -> Verifying existing data!
16:21:05.635 -> Verifying after write
16:21:05.742 -> Going back to idle
16:21:05.742 -> Waiting for command
16:21:06.119 -> Received command: POST_WRITE_VERIFY WRITE_ERASE_IF_NEEDED
16:21:06.119 -> Destination address: 20480
16:21:06.152 -> Size: 16384
16:21:06.152 -> Initialising serial flash
16:21:06.152 -> Done initialising
16:21:06.152 ->............

Hi All,

I saw this older post: https://community.cypress.com/t5/forums/searchpage/tab/message?advanced=false&allow_punctuation=false&q=large%20MQTT%20packets

and have recently run into the exact same problem with the CYW43907, and WICED Studio v6.4.  When using secure MQTT with TLS, we can transmit large packets (50 KB say), but we cannot receive them.  We see TCP receive errors, 0 sized TCP windows, and then we get disconnected from the MQTT broker with a "socket error".  The same large message works great without TLS.  We are using NetX Duo by the way.  Was the problem (originally reported back in 2018) ever fixed?

Hello,

When I build a firmware with WHL, I have 3 large files that are used by WHD to update the cypress module CYW94343.

• "wifi_firmware_image_data";"0x080605d4";"0x080605d4";"409,96 KB"
• "brcm_patchram_buf";"0x080c8a54";"0x080c8a54";"34,46 KB"
• "wifi_firmware_clm_blob_data";"0x080c6dbc";"0x080c6dbc";"7,05 KB"

Because of those files, it's impossible to flash the FW on a STM32 with only 512Kbytes without external flash. From what I understand, firmware image data are only "patch".

With WICED there isn't any of these file and I can flash the test board CYW94343WWCD1 with only 512KB of flash. Flash and static RAM reservation are:

snip.wifi_connection_manager-CYW94343WWCD1_EVB
----------------------------------|---------|---------|
                                  |         |  Static |
              Module              |  Flash  |   RAM   |
----------------------------------+---------+---------|
App                               |    1598 |      40 |
connection_manager                |    8856 |    5816 |
crc                               |    1060 |       0 |
DHCP_Server                       |    1454 |     132 |
DNS                               |      92 |      44 |
Host MCU-family library           |   16422 |    2690 |
Interrupt Vectors                 |     388 |       0 |
libc                              |   24803 |    3372 |
mbedTLS                           |   18388 |       0 |
Networking                        |    3611 |   19536 |
NetX-Duo - Interfaces & Stacks    |       0 |      16 |
Other                             |   55400 |     677 |
Packet Buffers                    |       0 |   22470 |
platform                          |    1456 |     288 |
RAM Initialisation                |    3196 |       0 |
resources                         |      44 |       0 |
Ring_Buffer                       |     112 |       0 |
SPI_Flash_Library_CYW94343WWCD1_EV|     512 |       0 |
Startup Stack & Link Script fill  |      76 |       9 |
Supplicant - BESL                 |   21323 |    5858 |
ThreadX                           |    8624 |     400 |
TLV                               |     216 |       0 |
WICED                             |    4315 |    1028 |
Wiced_RO_FS                       |     566 |       0 |
WWD                               |   20127 |    3208 |
----------------------------------+---------+---------|
TOTAL (bytes)                     |  189443 |   65584 |
----------------------------------|---------|---------|

Do you have any information about this? Is WICED don't update the CYW94343 and keep stock firmware?

Thank you

I want to run the mfg_test on my target board, which doesn't have any of the peripherals that the EVB has.

When I connect the EVB to my host processor UART pins, the mfg_test runs correctly, but when I program the same elf onto the Type1LD on my target board, it fails at the first command of 

wl43438A1.exe --serial 6 ver

Some serial bytes come back, but nothing like the full response string seen from the EVB.

Is there a list of HW dependencies for mfg_test, or a way of compiling the project without external HW dependencies? To start with, I don't have an SPI flash connected to my Type1LD.

I should say that the snip.uart works fine on my target board, so I have no problem running elfs, and no problem with the UART connection. I have also been able to run the bt_mfg_test in my target.

Thanks in advance.

We are integrating  Murata 1MW [ WiFi + BT ] module integration with AM335x - Beaglebone Black Board.

We have followed steps for building FMAC as documented in Cypress README file in the FMAC release from above repo [ifx-linux-wireless ].

After compiling and loading modules  [compat.ko, cfg80211.ko, brcmutil.ko, brcmfmac.ko,], we are getting below prints from dmesg.

[ 653.833301] compat: loading out-of-tree module taints kernel.
[ 653.848233] Loading modules backported from Linux version v5.4.18-2021_0520-0-gc6ec8acef0b8
[ 653.861348] Backport generated by backports.git v5.4.27-1-0-gf6e8852f
[ 654.969397] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 654.995533] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 657.124992] brcmfmac: brcmfmac_module_init No platform data available.
[ 657.125234] usbcore: registered new interface driver brcmfmac

It seems like we are struggling with dtb [Device tree blob] changes for sdio (wifi) and uart (BT) interfaces in am33x. Can you suggest changes for same ? 

Please find dtsi file [am335x-boneblack-wireless-1mw.zip] for am335x in attachments.

Thank You

DS