Skip navigation
Home > All Places > Software Forums > WICED Studio Wi-Fi/Combo > WICED Studio Wi-Fi/Combo Forums > Blog > Authors RaktimR_11

By default the LwIP standard debug prints are disabled to save memory and re-use the same for other parts of application threads. But in-case, you need to enable the standard debug prints in LwIP stack, which is done by LWIP_DEBUGF, you need to follow the steps mentioned below.


lwipopts for WICED SDK can be found in 43xxx_Wi-Fi/WICED/network/LwIP/WWD/FreeRTOS/lwipopts.h. If you are on a DEBUG build (specified by -debug in the make target), WICED_LWIP_DEBUG macro will be enabled, but the prints are still disabled by default.


A standard snip example is considered to demonstrate the how-to operation for a DEBUG build.


  1. Make Target: snip.tcp_client-<platform_name>-FreeRTOS-LwIP-debug download


    2. Switch the LWIP_DBG_TYPES_ON to LWIP_DBG_ON


    3. To enable specific debug messages in LWIP, just set the specific define value for the *_DEBUG value to " LWIP_DBG_ON". A comprehensive list of debug                          defines that can be enabled usually found in the 43xxx_Wi-Fi/WICED/network/LwIP/ver2.0.3/src/include/lwip/opt.h file. You need to copy the defines          for the  debug messages you want to enable into the lwipopts.h file and enable them there. As an example, I have switched the following on in my lwipopts.h file

#define TCP_DEBUG                       LWIP_DBG_ON
#define ETHARP_DEBUG                    LWIP_DBG_ON
#define PBUF_DEBUG                      LWIP_DBG_ON
#define IP_DEBUG                        LWIP_DBG_ON
#define TCPIP_DEBUG                     LWIP_DBG_ON
#define DHCP_DEBUG                      LWIP_DBG_ON
#define UDP_DEBUG                       LWIP_DBG_ON

Attached is the modified lwipopts.h file and and the uart terminal print. Please note that enabling debug prints can add extra size (approximately 20 kB for the mentioned settings) to the code. It will also slow down performance of the LwIP code due to required run-time checks and output. It's is recommended to enable debug support only if there is no chance of attaching an external debugger to the target platform and step through the code.



This document talks about how to use the waf.sflash_write.tcl script to read, write, erase the external flash that is already supported in WICED. For details about list of supported sflash, you can refer to SFLASH support addition in WICED


Erase sflash:

The procedure sflash_erase defined inside waf.sflash_write.tcl script takes two arguments

proc sflash_erase { PlatBusDebug init4390 }

-PlatbusDebug signifies the host interface between host and the radio card (For 4390x it’s SoC; details can be found in 43xxx_Wi-Fi/WICED/WWD/internal/bus_protocols)

-init4390 signifies the initialization sequence for the host (although parameter name is kind of a misnomer)

Platbus debug for any EVK can be found in the build directory once you have built any snip example which automatically generates the sflash.elf file as a part of WICED buildsystem.

For 4390x based device: Migrate to the SDK installation folder (e.g C:\Users\<user_name>\Documents\WICED-Studio-6.4 \43xxx_Wi-Fi) and launch CMD there.

For 4390x based device, PlatbusDebug translates to CYW943907AEVAL1F-P103-SoC.43909 and init4390 parameter translates to 43909


>tools\OpenOCD\Win32\openocd-all-brcm-libftdi.exe -f tools\OpenOCD\CYW9WCD1EVAL1.cfg -f tools\OpenOCD\BCM4390x.cfg -f apps\waf\sflash_write\sflash_write.tcl -c "sflash_erase CYW943907AEVAL1F-P103-SoC.43909 43909" -c shutdown



For ST Host based device:

The OpenOCD command for ST host based device is modified as below. PlatbusDebug: BCM94343WWCD2-SDIO and init4390: 0


>tools\OpenOCD\Win32\openocd-all-brcm-libftdi.exe -f tools\OpenOCD\CYW9WCD1EVAL1.cfg -f tools\OpenOCD\stm32f4x.cfg -f apps\waf\sflash_write\sflash_write.tcl -c "sflash_erase BCM94343WWCD2-SDIO 0" -c shutdown



For P6 Host based device:

The OpenOCD command for erasing the ext flash of P6 Host based platforms is mentioned below. PlatbusDebug: CYW943012P6EVB_01-SDIO and init4390: 6


>tools\OpenOCD\Win32\openocd-all-brcm-libftdi.exe -s tools\OpenOCD\scripts -f tools\OpenOCD\cmsis-dap.cfg -f tools\OpenOCD\psoc62.cfg -f apps\waf\sflash_write\sflash_write.tcl -c "sflash_erase CYW943012P6EVB_01-SDIO 6" -c shutdown



On successful completion of the erase operation, user should be able to see the following message in cmd

****************** Result: OK

Chip Erase Done (in 25097 ms)


Read sflash :

proc sflash_read_file { filename srcAddress PlatBusDebug length init4390 }

- filename: output filename for binary image file (.bin format)

- srcAddress: The serial flash starting address to be read from

- length: Number of bytes to be read

To check the successful erase operation, sflash_write.tcl script can be used to read a section of the external flash.


For 4390x based device:


tools\OpenOCD\Win32\openocd-all-brcm-libftdi.exe -f tools\OpenOCD\CYW9WCD1EVAL1.cfg -f tools\OpenOCD\BCM4390x.cfg -f apps\waf\sflash_write\sflash_write.tcl -c "sflash_read_file contents.bin 2097152 CYW943907AEVAL1F-P103-SoC.43909 512 43909" -c shutdown



The above command reads the content of 512 bytes starting from 2097152 (in decimal).


For ST Host based device:

>tools\OpenOCD\Win32\openocd-all-brcm-libftdi.exe -f tools\OpenOCD\CYW9WCD1EVAL1.cfg -f tools\OpenOCD\stm32f4x.cfg -f apps\waf\sflash_write\sflash_write.tcl -c "sflash_read_file contents.bin 0 BCM94343WWCD2-SDIO 512 0" -c shutdown


For P6 Host based device:


>tools\OpenOCD\Win32\openocd-all-brcm-libftdi.exe -s tools\OpenOCD\scripts -f tools\OpenOCD\cmsis-dap.cfg -f tools\OpenOCD\psoc62.cfg -f apps\waf\sflash_write\sflash_write.tcl -c "sflash_read_file contents.bin 0 CYW943012P6EVB_01-SDIO 512 6" -c shutdown





For Write operation, user can use the VERBOSE=1 in Make Target and check the usage of sflash_write_file API in CDT log to manually perform the external flash write operation.

This blog post discusses how to run a restricted set of WL commands along with iperf for limited memory platforms like BCM943438WCD1, CYW94343WWCD1_EVB, CY8CKIT-062 (A typical use-case would be something like adaptivity testing)

  1. If you are running the test.console example with CONSOLE_ENABLE_WL set to 1 and getting the APP_CODE overflow error, please follow the steps mentioned below to enable the particular set of WL commands your application requires.
  2. In file, please mark CONSOLE_ENABLE_WL :=  0. Along with that, you can make use of certain macros listed below to save some further memory.










                       WICED_CONFIG_DISABLE_SSL_SERVER \

                       WICED_CONFIG_DISABLE_DTLS \


                       WICED_CONFIG_DISABLE_DES \



      3. Now, you can use one more macro to enable a limited set of WL commands for your application.


          This enables some fixed wifi related commands defined inside 43xxx_Wi-Fi/libraries/utilities/command_console/wifi/command_console_wifi.h


     4. The idea is now to keep adding the application specific WL commands to the WIF_LIMITED_SET_COMMANDS by modifying the existing code in 43xxx_Wi-Fi/libraries/utilities/command_console/wifi/command_console_wifi.h and 43xxx_Wi-Fi/libraries/utilities/command_console/wifi/command_console_wifi.c


     5. I am going to take up a sample WL command like wl down for which the sequence is mentioned below (modified command is wl_down):


    1. Add

{ (char*) "wl_down", wl_down, 0, NULL, NULL, (char*) "", (char*) "Getting the driver down"}, \

under the #define WIFI_COMMANDS_LIMITED_SET \

           b. Time to declare the wl_down function inside command_console_wifi.h

      int wl_down                (int argc, char* argv[] );

           c. The function may be defined in the following manner inside command_console_wifi.c

int wl_down(int argc, char* argv[])


wwd_result_t result = wwd_wifi_set_down();


if (result != WWD_SUCCESS)


        WPRINT_APP_INFO(("WLAN Driver down failed with result %d\n,result"));



    return result;



     6. Let’s try to take one more WL command like wl bi and follow almost the same steps as mentioned in 5a, 5b. But the function definition inside command_console_wifi.c will use some ioctl/iovar to set the parameter.

int wl_bi(int argc, char* argv[])


wwd_result_t result;

uint32_t bi = atoi(argv[1]);


result = wwd_wifi_set_ioctl_value(WLC_SET_BCNPRD, bi, WWD_STA_INTERFACE);


if(result != WWD_SUCCESS)


        WPRINT_APP_INFO(("Setting beacon interval failed with %d\n", result));



          return result;



More details on how to use the ioctl/iovars from application, you can go through  How to use IOCTL commands in CYW43907


To add any other WL command, you can first look for WWD APIs which can serve the same purpose inside 43xxx_Wi-Fi/WICED/WWD/include/wwd_wifi.h. If there is no such API available, you can look for the list of IOCTLs inside 43xxx_Wi-Fi/libraries/test/wl_tool/<chip_name>/common/include/devctrl.h and use the IOCTL GET/SET APIs to define the particular WL command.


An example screenshot for the above mentioned wl_down command can be found below.

WICED currently has support for sflash from the following manufacturers.

  3. SST
  4. EON
  5. ISSI

You can get a list of all the supported sflash in CYW43907 with External SFLASH in WICED . If you want to add support for any other part number from the existing supported flash manufacturers in WICED SDK, you can follow the steps mentioned below. In this example, I have added support for N25Q128A flash from MICRON.


For ST based platforms:

  • Please add the SFLASH_ID from the part number datasheet in 43xxx_Wi-Fi/libraries/drivers/spi_flash/spi_flash_internal.h

    #define SFLASH_ID_MX25L8006E           ( (uint32_t) 0xC22014 )

    #define SFLASH_ID_MX25L1606E           ( (uint32_t) 0xC22015 )

    #define SFLASH_ID_MX25L6433F           ( (uint32_t) 0xC22017 )

    #define SFLASH_ID_MX25L12835F          ( (uint32_t) 0xC22018 )

    #define SFLASH_ID_MX25L25635F          ( (uint32_t) 0xC22019 )

    #define SFLASH_ID_MX25U1635F           ( (uint32_t) 0xC22535 )

    #define SFLASH_ID_MX66U51235F          ( (uint32_t) 0xC2253A )

    #define SFLASH_ID_SST25VF080B          ( (uint32_t) 0xBF258E )

    #define SFLASH_ID_EN25QH16             ( (uint32_t) 0x1C3015 )

    #define SFLASH_ID_ISSI25CQ032          ( (uint32_t) 0x7F9D46 )

    #define SFLASH_ID_N25Q512A             ( (uint32_t) 0x20BB20 )

    #define SFLASH_ID_ISSI25LP064          ( (uint32_t) 0x9D6017 )

    #define SFLASH_ID_N25Q064A             ( (uint32_t) 0x20BA17 )

    #define SFLASH_ID_W25Q64FV             ( (uint32_t) 0xEF4017 )

    #define SFLASH_ID_CY15B104Q            ( (uint32_t) 0x7F7F7F )

    +#define SFLASH_ID_N25Q128A             ( (uint32_t) 0x20BA18 )


    #define SFLASH_ID_DEFAULT              ( (uint32_t) 0x000000 )


  • Then try adding the size of the new part number in 43xxx_Wi-Fi/libraries/drivers/spi_flash/spi_flash_internal.h


   #define SFLASH_SIZE_1MByte                0x100000

   #define SFLASH_SIZE_2MByte                0x200000

   #define SLFASH_SIZE_32MByte               0x2000000

   #define SFLASH_SIZE_64MByte               0x4000000

   #define SFLASH_SIZE_512KByte              0x80000

   #define SFLASH_SIZE_16MByte               0x1000000


  • Add the device name in the sflash_device_id_size structure in the following manner


         device_id_to_flash_size_t sflash_device_id_size [SFLASH_ID_MAX_PARTS] =


                { SFLASH_ID_MX25L8006E,  SFLASH_SIZE_1MByte   },

                { SFLASH_ID_MX25L1606E,  SFLASH_SIZE_2MByte   },

                { SFLASH_ID_MX25L25635F, SLFASH_SIZE_32MByte  },

                { SFLASH_ID_MX25U1635F,  SFLASH_SIZE_2MByte   },

                { SFLASH_ID_SST25VF080B, SFLASH_SIZE_1MByte   },

                { SFLASH_ID_EN25QH16,    SFLASH_SIZE_2MByte   },

                { SFLASH_ID_N25Q512A,    SFLASH_SIZE_64MByte  },

                { SFLASH_ID_CY15B104Q,   SFLASH_SIZE_512KByte },

                { SFLASH_ID_N25Q128A,    SFLASH_SIZE_16MByte  }




  • If you are using WINBOND, ISSI, CYPRESS flash, you have to add SFLASH_SUPPORT_WINBOND_PARTS in 43xxx_Wi-Fi/libraries/drivers/spi_flash/ or as a part of GLOBAL_DEFINES in your <platform>.mk file



For 4390x based platform


To add a new part with the already supported sflash chips for 4390x platform, you have to make the necessary modifications in 43xxx_Wi-Fi/WICED/platform/MCU/BCM4390x/peripherals/spi_flash.


  • Just like ST based platforms, you need to add the SFLASH_ID in 43xxx_Wi-Fi/WICED/platform/MCU/BCM4390x/peripherals/spi_flash/spi_flash.h


      #define SFLASH_ID_MX25L8006E           SFLASHID( 0xC2, 0x20, 0x14 )


      #define SFLASH_ID_MX25L1606E           SFLASHID( 0xC2, 0x20, 0x15 )


      #define SFLASH_ID_MX25L6433F           SFLASHID( 0xC2, 0x20, 0x17 )


      #define SFLASH_ID_MX25L12835F          SFLASHID( 0xC2, 0x20, 0x18 )


      #define SFLASH_ID_MX25L25635F          SFLASHID( 0xC2, 0x20, 0x19 )


      #define SFLASH_ID_MX25U1635F           SFLASHID( 0xC2, 0x25, 0x35 )


      #define SFLASH_ID_MX66U51235F          SFLASHID( 0xC2, 0x25, 0x3A )


      #define SFLASH_ID_SST25VF080B          SFLASHID( 0xBF, 0x25, 0x8E )


      #define SFLASH_ID_EN25QH16             SFLASHID( 0x1C, 0x30, 0x15 )


      #define SFLASH_ID_ISSI25CQ032          SFLASHID( 0x7F, 0x9D, 0x46 )


      #define SFLASH_ID_N25Q512A             SFLASHID( 0x20, 0xBB, 0x20 )


      #define SFLASH_ID_ISSI25LP064          SFLASHID( 0x9D, 0x60, 0x17 )


      #define SFLASH_ID_N25Q064A             SFLASHID( 0x20, 0xBA, 0x17 )


      #define SFLASH_ID_W25Q64FV             SFLASHID( 0xEF, 0x40, 0x17 )


      #define SFLASH_ID_S25FL064L            SFLASHID( 0x01, 0x60, 0x17 )


      #define SFLASH_ID_S25FL128L            SFLASHID( 0x01, 0x60, 0x18 )


      #define SFLASH_ID_S25FL256L            SFLASHID( 0x01, 0x60, 0x19 )


      #define SFLASH_ID_N25Q128A             SFLASHID( 0x20, 0xBA, 0x18 )


      #define SFLASH_ID_DEFAULT              SFLASHID( 0x00, 0x00, 0x00 )



  • In 43xxx_Wi-Fi/WICED/platform/MCU/BCM4390x/peripherals/spi_flash/spi_flash.c, you have to add the part number information in sflash_capabilities_tables structure.


              { SFLASH_ID_N25Q064A,       { 8*MBYTE,    256,  .action = &micron_action,   .speed_advance = &micron_speed_config } },

              { SFLASH_ID_N25Q128A,       { 16*MBYTE,   256,  .action = &micron_action,   .speed_advance = &micron_speed_config } },


  •      If you are using any flash other than macronix flash, you have to add support in <platform_name>.mk file in the following manner.



Debugging Notes:

  • Please check for DEBUG_PRINT macro in 43xxx_Wi-Fi/apps/waf/sflash_write/sflash_write.c. Once you enable this macro, you should be able to see debug prints in the UART terminal where you should look for SFLASH ID and SFLASH size. If the support is correctly added, these two fields will show you the correct SFLASH ID and the size that you have added following the above mentioned steps.

          SFLASH Device ID ( 0x20ba18)
     SFLASH Size      ( 0x1000000)

  • The micron flash (N25Q128A) I have added in this example needed a 100k pull up resistor in the RESET pin as specified by the datasheet. Please check similar things in the datasheet of the flash you plan to add.
  • This blog post does not cover the porting effort of flash from a different manufacturer, in which case, you have to add the read, write, erase source code in the spi_flash.c for which you can refer to the already existing implementations.


This blog provides a guideline to add support ST-Link (ST Micro’s programming & debug hardware) in an existing WICED SDK framework.



Consider this document as a guideline, which has not been extensively tested and the procedure mentioned below could differ for different versions of WICED Studio & ST-Link.




ST-Link is the on-board programmer used to program the code in ST MCU, details of which can be found at ST website. WICED uses OpenOCD to download the programs to the target MCU (ST host MCU, CYW43907, PSoC 6). In most of the standard WICED EVBs, an FTDI chip (FT2232H) has been used to provide the USB-UART  / USB-JTAG bridge functionality which is what has been the standard download procedure followed by the OpenOCD in WICED.




Brief Introduction about OpenOCD

Open On-Chip Debugger (OpenOCD) is a free open-source project that facilitates downloading, debugging by using a debug adapter like ST-Link, FT2232H etc. OpenOCD works either by using commands or by using configuration files. When configuration is done and a connection to the target is established, OpenOCD will start running as a daemon in the background. The OpenOCD directory file has a folder called “scripts”. In this folder, you will see "interface", "board", and "target" folders. These are pretty much the only folders you need.

  • Interface: Configuration files for hardware adapters, for example “stlink-v2-1.cfg”.
  • Board: Configuration files for common development boards like “stm32f469discovery.cfg” .. etc. You can see that these files reuse configuration files from interface and target.
  • Target: Configuration files for MCU Chips.

For detailed understanding of OpenOCD procedure and syntax, one can find their documentation at




WICED Download and debug procedure:

  In WICED, an OpenOCD command is put into the .gdbinit file by the makefile system during compilation.
Wiced Eclipse has an optional component "GDB Hardware Debugging" installed.  This allows it to instruct GDB to access a "GDB remote protocol server" via TCP.
Hence when Eclipse starts a debug session, it starts GDB, which in turn causes the .gdbinit OpenOCD command to be executed. OpenOCD is a "GDB remote protocol server", and next, Eclipse instructs GDB to connect to it.
During the startup of OpenOCD, it uses various JTAG & ARM protocols to interrogate the target chip. Once this initial interrogation is done, OpenOCD receives requests over TCP from GDB and services those requests on the target chip as needed details about this remote GDB can be found at GDB documentation.



How to add support for ST-Link:

WICED Environment uses the makefiles, configuration files as located in 43xxx_Wi-Fi/tools/makefiles and 43xxx_Wi-Fi/tools/OpenOCD respectively to download the code to the target MCU. Some changes have been made in the makefiles responsible for the download process and rest of the modifications were done in the OpenOCD directory, details of which can be found in the attached. Please note that modifying the existing makefiles, OpenOCD directory to enable ST-Link support is a one-way approach; i.e, you can’t program the other WICED boards (using a FT2232H chip) normally without restoring both directories back to the one shipped with SDK. So, it’s always recommended to make a back-up of the directories before replacing them with the attached.


In the example implementation, a custom JTAG macro was defined in the platform makefile ( in the following way.




Based on the custom JTAG macro, openocd binary (openocd-all-brcm-libftdi.exe), as located in 43xxx_Wi-Fi/tools/OpenOCD/Win32/openocd-all-brcm-libftdi.exe expects a <custom JTAG macro>.cfg file in the 43xxx_Wi-Fi/tools/OpenOCD directory as shown in the figure below.

In this case, the stm32f469discovery.cfg file was copied from 43xxx_Wi-Fi/tools/OpenOCD/scripts/board/stm32f469discovery.cfg directory to the 43xxx_Wi-Fi/tools/OpenOCD directory. This stm32f469discovery.cfg has all the necessary interface, transport, target, reset_config specified. For a created platform, customer needs to create their own .cfg file based on the JTAG macro chosen and place them in 43xxx_Wi-Fi/tools/OpenOCD directory. If the created .cfg file has some error, a good place to start the debug procedure would be the openocd log generated as part of the build system which can be found at 43xxx_Wi-Fi/build/openocd_log.txt.


Refer to the files attached to this blog. We suggest you do a ‘Diff’ of the existing WICED Studio files and the attached files to understand the changes.

This blog post discusses the antenna diversity feature available in CYW43907, streamlined for robust Wi-Fi connectivity. CYW943907AEVAL1F has two PCB antennas to improve the quality and reliability of a wireless link in a non-static environment. In this device, a running average SNR  is maintained for each antenna amongst which antenna with better SNR is chosen to support changing environmental conditions.

Hardware Schematic

The CYW943907AEVAL1F EVK has provision for two external antennas along with the on-board PCB antennas (ANT 0 & ANT 1). Two external antennas are connected to the J1 and J2 connector which has an internal switch connected to it. When an External antenna is connected to J1 and J2 PCB antennas are automatically dis-connected.

Note: After connecting the external antennas in the J1 and J2 connector, please make sure I and O pins of J1/J2 are shorted. Else press the external antennas properly. The CYW43907 has ANT0_DIV_RF_SW_CTRL_4, ANT1_DIV_RF_SW_CTRL_5 control signals which are routed to an SPDT switch (U7) which works based on the following truth table.

VCON1 (5 of U7)

VCON2 (2 of U7)

ANT0 (4 of U7)ANT1 (3 of U7)


NVRAM Parameters

For Antenna diversity to be enabled following NVRAM parameters should be enabled. Please refer to following link for more details about NVRAM parameters

  1. swdiv_en:  0 - disable software diversity; 1 - enable software diversity
  2. swdiv_gpio: specify which GPIO pin will be used for software diversity control (for CYW943907AEVAL1F swdiv_gpio = 0 because we are not controlling the antenna diversity through GPIO)
  3. swdiv_swcntrl_en: diversity mode control variety; 4390x is using mode 2 (controlled by Phy layer)
  4. swdiv_swctrl_ant0, swdiv_swctrl_ant1=1: entries used as shared memory setting for ucode activity, now uses mode 1 (swdiv_swctrl_ant0 = 0, swdiv_swctrl_ant1 = 1)


A sample application is attached to this blog post which calls the IOCTLs to check the active antenna. Please refer to How to use IOCTL commands in CYW43907  to understand the way APIs are being used. The definitions of the used IOCTLs are provided below.


WLC_SET_ANTDIV-1: default antdiv setting; 0: Force reception on antenna 0; 1: Force reception on antenna 1; 2: Start diversity reception with antenna 1; 3: Start diversity reception with antenna 0
WLC_GET_ANTDIVReturns the current antenna diversity method in use
WLC_GET_RX_ANTReturns last used RX antenna



In our environment, some attenuators are introduced in one of the two antenna paths; hence the antenna diversity algorithm should select the other antenna after a brief settling period which can be displayed in the oscilloscope if you probe 2nd and 5th pin of U7 (shown in below image). 

WhatsApp Image 2017-12-06 at 3.30.40 PM (2).jpeg

WhatsApp Image 2017-12-06 at 3.30.40 PM (1).jpeg

So, by probing the pins of U7, the user can match the console log with the physical signals going into the antennas.


WL commands for antenna diversity

Following are the WL commands that are used to control antenna diversity instead of being controlled by application.

  1. wl antdiv <value>
    • 0 Forces the use of antenna 0
    • 1 Forces the use of antenna 1
    • 3 Automatic selection of antenna diversity
  2. wl swdiv_reset_stats - Resets the antenna diversity statistics
  3. wl swdiv_stats - returns the antenna diversity related statistics




Posted by RaktimR_11 Moderator Dec 5, 2017

This blog post provides an overview of the UART interfaces available in CYW43907, which has three UART ports and a sample application is provided to transmit data using any one of the three UART ports.

  1. Slow UART
    1. 16650 compatible 2-wire
    2. RX and TX buffers are both of 1 byte
    3. Can support 115.2 Kbps baud rate
  2. Fast UART
    1. 4 wire (TX/RX/CTS/RTS) UART
    2. Can support 3 Mbps baud rate
    3. RX and TX buffers are both of 64 bytes
    4. Supports interrupts and HW handshaking
    1. Typically used for WLAN/BT coexistence.

The tables below display the pin assignment of CYW943907AEVAL1F kit for the above mentioned three UART ports.


MURATA Module Pin NameWICED Header


WICED_UART_2 (Fast UART)MURATA Module Pin NameWICED HeaderArduino Header


WICED Header


If the user wants to use Fast or GCI UART on this platform, they can choose the clock frequency based on the allowable baud rate error which is provided in the following tables. If the user wants to save on the active power consumption, it is advisable to go for the CLOCK_ALP (can be modified in platform_uart.c).


Rate Error when src_clk = CLOCK_ALP



Nominal Baud RateTarget Baud RateActual Baud Rate
Rate Error


Rate Error when src_clk = CLOCK_HT



Nominal Baud RateTarget Baud RateActual Baud RateRate Error




A sample application is provided in this blog to demonstrate the usage of the WICED UART APIs to send characters on the UART. By default, Slow UART will be used for data transmission; based on the user choice (USER_1 button press), fast UART, GCI UART, slow UART ports will be selected to transmit the same data.


The APIs available for configuring a UART is available in the location


  1. wiced_uart_init(wiced_uart_t uart, const wiced_uart_config_t* config, wiced_ring_buffer_t* optional_rx_buffer )
    1. uart: The interface which should be initialized, platform header file enumerates interfaces from WICED_UART_0 to WICED_UART_MAX.
    2. config: UART configuration structure, defined in WICED/platform/include/platform_peripheral.h
    3. optional_rx_buffer: Pointer to an optional RX ring buffer
  2. wiced_uart_transmit_bytes( wiced_uart_t uart, const void* data, uint32_t size )
    1. data: Pointer to the start of data
    2. size: Number of bytes to transmit
  3. wiced_uart_receive_bytes( wiced_uart_t uart, void* data, uint32_t* size, uint32_t timeout )
    1. data: Pointer to the buffer which will store incoming data
    2. size: Specifies number of bytes to receive; returns number bytes received and placed in the data buffer
    3. timeout: Timeout in milliseconds. WICED_WAIT_FOREVER and WICED_NO_WAIT can be specified for infinite and no wait.
  4. The definitions of the above APIs are found in



To access STDIO_UART using the generic UART APIs, it is necessary to add a global define WICED_DISABLE_STDIO in the

This blog tries to provide a guide for using IOCTL commands. Essentially, WL commands are functions that send an IOCTL or sequence of IOCTLs and process the received data. An alternate way to achieve the same is directly using IOCTL/IOVAR commands. IOCTL  basically stands for "input-output control", which are used to define device-specific system call (in specific WLAN calls). A driver can define an IOCTL which allows APPS Core (ACPU) application to send commands to the WLAN driver; which can ultimately be used to update the configurations of the WLAN. Any user application API internally calls the IOCTL/IOVARs to communicate with the WLAN core. The host interface between WLAN subsystem (WCPU) and the host processor (ACPU) is through the memory to memory DMA engine which uses Cypress proprietary SDPCM protocol for this communication. The SDPCM protocol provides multiplexing of data packets, IOVAR/IOCTL, and asynchronous event signalling allowing a communication between host driver and WLAN firmware.


To use the IOCTL/IOVAR commands directly from the application, the user can use the WWD APIs listed in WICED SDK. For wifi related parameters (like getting the RSSI, setting the transmit antenna, checking the active antenna), the APIs' can be found in wwd_wifi.c. The list of  valid IOCTLs are  provided in


Similarly, the list of valid IOVARs are provided in


The definition of the above-mentioned IOVARs for the specific platform are provided in



The APIs used to send an IOCTL/IOVAR command or receive a status of  an IOCTL/IOVAR are given by wwd_wifi_set_ioctl/iovar_value and wwd_wifi_get_ioctl/iovar_value. For instance, to set the transmit antenna the format of this API should be


wwd_wifi_set_ioctl_value(WLC_SET_TXANT, 1, WWD_STA_INTERFACE)


The WLC_GET_VAR and WLC_SET_VAR IOCTLs provide a method of getting and setting internal wl driver state values.

  • WLC_GET_VAR takes a NULL-terminated ASCII string name
  • WLC_SET_VAR takes a NULL-terminated ASCII string name followed by an optional value


The name of the IOCTL (WLC_SET_TXANT) used in the example usage of APIs could be located in




A sample application is provided here to test the RSSI using IOCTLs, scan association time using IOVARs and the same is verified using standard WL commands (wl phy_rssi_ant, wl scan_assoc_time).



Unbricking of CYW943907

Posted by RaktimR_11 Moderator Oct 27, 2017

This post discusses how to recover a bricked CYW943907 device on CYW943907AEVAL1F  kit due to incorrect clock settings.


The CYW43907 boots from internal ROM and then loads an application from external sflash.

By mistake, if a corrupted application (wrong clock setting etc) is flashed into sflash, then there is a fair amount of possibility that sflash may not be able to be programmed (For instance, setting the sflash clock to 25 MHz).


In this case, the only way is to make sure that program in sflash not to be executed. The easiest way is to short the chip select (CS_L) to High while the device is getting booted. Once this is done, we can upload a new example using the build target in WICED studio. The following diagrams show the necessary hardware connection required to pull the chip select pin of the sflash high.


Filter Blog

By date:
By tag: