The CYW954907AEVAL1F EVK enables customers to evaluate and develop single-chip Wi-Fi applications using CYW54907 devices. The CYW954907AEVAL1F EVK uses WICED Studio IDE to develop and debug your CYW54907 projects. In this code example, I have interfaced Infineon's precision pressure sensor DPS310 to the 54907 evaluation board and measured the temperature and pressure values of the surroundings via I2C. The required pins of the sensor are --> VDD(Supply Voltage 3.3V for analog blocks), VDDIO (Digital Supply Voltage 3.3V for digital blocks and I/O interface), GND, SDI and SCK. The application is implemented in WICED STUDIO IDE. The provided code example for DPS310 can be used for various IOT applications such as indoor navigation, health and sports, outdoor navigation, weather station etc.

Let's get started with the sensor's introduction!

The Infineon's DPS310 is a miniaturized Digital Barometric Air Pressure Sensor with a high accuracy and a low current consumption, capable of measuring both pressure and temperature. The pressure sensor element is based on a capacitive sensing principle which guarantees high precision during temperature changes. The small package makes the DPS310 ideal for mobile applications and wearable devices.

The internal signal processor converts the output from the pressure and temperature sensor elements to 24 bit results. Each unit is individually calibrated, the calibration coefficients calculated during this process are stored in the calibration registers. The coefficients are used in the application to convert the measurement results to high accuracy pressure and temperature values. The result FIFO can store up to 32 measurement results, allowing for a reduced host processor polling rate. Sensor measurements and calibration coefficients are available through the serial I2C or SPI interface. The measurement status is indicated by status bits or interrupts on the SDO pin.

For more features information and typical applications, refer to the DPS310 datasheet attached.

Temperature and Pressure Measurement

Calculation of Compensated Values

1. Read the pressure calibration coefficients (c00, c10, c20, c30, c01, c11, and c21) from the Calibration Coefficient register. Note: The coefficients read from the coefficient register are 2's complement numbers.

2. Choose scaling factors kT (for temperature) and kP (for pressure) based on the chosen precision rate. The scaling factors are listed in datasheet.

3. Read the pressure and temperature result from the registers or FIFO. Note: The measurements read from the result registers (or FIFO) are 24 bit 2´s complement numbers. Depending on the chosen measurement rates, the temperature may not have been measured since the last pressure measurement.

4. Calculate scaled measurement results.

5. Calculate compensated measurement results.

Known Issues

There could be a problem with temperature measurement of the DPS310. If your DPS310 indicates a temperature around 60 °C although you expect around room temperature, e.g. 20 °C, you have to update some registers with the specified values as given in the "DPS310_correct_temp_error" function in my code example and this will then provide the correct temperature value. As per Infineon, this can occur because of a fuse bit issue in some of the sensor's silicon. The function allows us to work around the issue.

For more information on this, please visit this link --> https://www.infineon.com/cms/en/product/sensor/pressure-sensors/pressure-sensors-for-iot/dps310/

PFA the code example and the snapshots for the same. Feel free to drop in your queries in the Cypress Developer Community.

Cheers!

Scope

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

Disclaimer

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.

Introduction

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 http://openocd.org/doc/html/index.html

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 (platform.mk) 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.

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.

Scope:

This Blog Post provides a guide on configuring the virtual AP interface as a STA interface in an existing WICED SDK framework.

Disclaimer:

Consider this document as a guide line and this feature hasn’t been tested extensively via any testing process. The examples attached have been tried on the 43907 and the 54907 platform and the application works.

Introduction:

Any Cypress WLAN chip can be operated as a STA (client), an AP (softAP), an ethernet interface or a P2P interface based on what is supported in that chip. Now, the STA, AP and P2P are nothing but virtual interfaces which the software creates. Most of our WLAN chips have the capability of operating these interfaces simultaneously. Most common is the operation of the WICED_STA_INTERFACE and the WICED_AP_INTERFACE. An example of this implementation can be found at /43xxx_Wi-Fi/apps/snip/apsta. Now instead of using one of the virtual interfaces as an AP, both the interfaces can be configured to be used as clients as discussed below.

Use Case:

As an example, this can be used say for example when a TCP and a UDP clients are needed to run simultaneously on a WLAN chip whereas the servers are running on two different networks.

Implementation:

The credentials for the second STA need to be defined in the respective wifi_config_dct.h file as below.

#define CLIENT_AP_2_SSID       "SSID_FOR_STA2"

#define CLIENT_AP_2_PASSPHRASE "PSK_FOR_STA2"

#define CLIENT_AP_2_SECURITY   WICED_SECURITY_WPA2_AES_PSK

#define CLIENT_AP_2_BSS_TYPE   WICED_BSS_TYPE_INFRASTRUCTURE

#define CLIENT_AP_2_CHANNEL    1

#define CLIENT_AP_2_BAND WICED_802_11_BAND_2_4GHZ

The WICED_AP_INTERFACE can be defined to function as a STA by un-commenting //#define WICED_USE_WIFI_TWO_STA_INTERFACE in wiced_defaults.h at /43xxx_Wi-Fi/include/

Once this is done, there are two ways of realizing the second STA.

The Easy Way:

Once the WICED_USE_WIFI_TWO_STA_INTERFACE is defined, all that needs to be done is connect the two clients from the application is as below.

wiced_network_up(WICED_STA_INTERFACE, wiced_network_config_t config, const wiced_ip_setting_t* ip_settings);

wiced_network_up(WICED_AP_INTERFACE, wiced_network_config_t config, const wiced_ip_setting_t* ip_settings);

The disadvantage of this is, if you go back to using the device in a single STA mode, the functionality of the application needs to be monitored to ensure that the device doesn’t throw errors during run time as these types of errors won’t be detected easily during compile time.

The Clean Way:

Here what can be done is the WICED_AP_INTERFACE can be defined as WICED_STA_2_INTERFACE as this would be much more comprehensible. There’s a small work around that needs to be done when doing this as WICED_AP_INTERFACE is intertwined in many places and this needs to be dealt with.

The changes to be done are as below

Change the wiced_interface_t enumeration in wiced_constants.h (/43xxx_Wi-Fi/include/) as

typedef enum

{

#ifndef WICED_USE_WIFI_TWO_STA_INTERFACE

    WICED_STA_INTERFACE      = WWD_STA_INTERFACE,         /**< STA or Client Interface  */

    WICED_AP_INTERFACE       = WWD_AP_INTERFACE,          /**< softAP Interface         */

    WICED_P2P_INTERFACE      = WWD_P2P_INTERFACE,         /**< P2P Interface            */

    WICED_ETHERNET_INTERFACE = WWD_ETHERNET_INTERFACE,     /**< Ethernet Interface      */

    WICED_INTERFACE_MAX,            /** DO NOT USE - MUST BE AFTER ALL NORMAL INTERFACES - used for counting interfaces */

    WICED_CONFIG_INTERFACE   = WICED_AP_INTERFACE | (1 << 7), /**< config softAP Interface  */

#else

    WICED_STA_INTERFACE      = WWD_STA_INTERFACE,        /**< STA or Client Interface  */

    WICED_STA_2_INTERFACE    = WWD_STA_2_INTERFACE,      /**< second STA Interface     */

    WICED_P2P_INTERFACE      = WWD_P2P_INTERFACE,        /**< P2P Interface            */

    WICED_ETHERNET_INTERFACE = WWD_ETHERNET_INTERFACE,   /**< Ethernet Interface    */

    WICED_INTERFACE_MAX,

    WICED_CONFIG_INTERFACE   = WWD_STA_2_INTERFACE | (1 << 7),

#endif

} wiced_interface_t;

Change the wwd_interface_t enumeration in wwd_constants.h (/43xxx_Wi-Fi/WICED/WWD/include/) as

typedef enum

{

#ifndef WICED_USE_WIFI_TWO_STA_INTERFACE

    WWD_STA_INTERFACE          = 0,        /**< STA or Client Interface*/

    WWD_AP_INTERFACE           = 1,        /**< softAP Interface*/

    WWD_P2P_INTERFACE          = 2,        /**< P2P Interface*/

    WWD_ETHERNET_INTERFACE     = 3,        /**< Ethernet Interface*/

    WWD_INTERFACE_MAX,          /** DO NOT USE - MUST BE LAST INTERFACE VALUE - used for counting interfaces */

    WWD_INTERFACE_FORCE_32_BIT = 0x7fffffff /**< Exists only to force wwd_interface_t type to 32 bits                    */

#else

WWD_STA_INTERFACE          = 0,         /**< STA or Client Interface*/

WWD_STA_2_INTERFACE        = 1,         /**< second STA Interface*/

WWD_AP_INTERFACE = WWD_STA_2_INTERFACE,

WWD_P2P_INTERFACE          = 2,         /**< P2P Interface*/

WWD_ETHERNET_INTERFACE     = 3,         /**< Ethernet Interface*/

WWD_INTERFACE_MAX,           /** DO NOT USE - MUST BE LAST INTERFACE VALUE - used for counting interfaces */

WWD_INTERFACE_FORCE_32_BIT = 0x7fffffff /**< Exists only to force wwd_interface_t type to 32 bits                    */

#endif

} wwd_interface_t;

And add the line #include "../../../include/wiced_defaults.h"

Add the following definition

#ifdef WICED_USE_WIFI_TWO_STA_INTERFACE

#define WICED_AP_INTERFACE WICED_STA_2_INTERFACE

#endif

in the files ,wifi.c (/43xxx_Wi-Fi/WICED/internal/), wiced_network_common.c(/43xxx_Wi-Fi/WICED/network/) ,wiced_network.c(/43xxx_Wi-Fi/WICED/network/NetX_Duo/WICED) [This will be depend on the network stack being used] and

command_console_wifi.c(/43xxx_Wi-Fi/libraries/utilities/command_console/wifi/)

Add the below lines in wwd_ap_common.c(/43xxx_Wi-Fi/WICED/WWD/internal/)

#ifdef WICED_USE_WIFI_TWO_STA_INTERFACE    

#define WWD_AP_INTERFACE WWD_STA_2_INTERFACE

#endif

Once the changes are done, upload the application on to your board, run the tcp_echo_server_py3.py and the udp_echo_server_py3.py on the respective networks and you should get the logs as below.

    在我们释放的文档中已经有比较详细的OTA2的步骤， 这篇博客的目的是让测试者可以更加快速的测试OTA2的应用，

有一个感官的认识，然后再回头去详细阅读SDK中释放的文档。

步骤如下：

1.   准备两个应用， 一个用于第一次下载到板子中，一个用于OTA2 升级的image。

    这里我测试使用的是snip. OTA2_example 和 snip.apsta , 在这两个应用的makefile中都需要添加：

#OTA SoftAp application

OTA_APPLICATION  := snip.ota2_extract-$(PLATFORM)

ifeq ($SECURE_SFLASH),1)

OTA_APP := build/$(OTA_APPLICATION)/binary/$(OTA_APPLICATION).stripped.elf.sig.enc

else

OTA_APP := build/$(OTA_APPLICATION)/binary/$(OTA_APPLICATION).stripped.elf

endif

2.  按照顺序来：

snip.ota2_extract-CYW943907AEVAL1F

Note:  这一步是用来编译解压的应用， 这部分的image也会被download 进入到外置flash中。

最终生成的image是： snip.ota2_extract-CYW943907AEVAL1F.stripped.elf

snip.apsta-CYW943907AEVAL1F ota2_image

Note:  这一步用来编译实际需要更新的应用， 这部分image最终会通过http server这种形式通过wifi 接口发送到

板子正在运行的应用中， 并写入到规定的区域，这部分区域叫做OTA2 staging area。

snip.ota2_example-CYW943907AEVAL1F ota2_factory_download

Note: 这部分会编译一个image 并下载到板子的出厂恢复区域， 这部分用来在运行的image 被毁坏的情况下恢复到可以运行的状态。

这部分可以选择其他的应用，不需要指定为ota2_example。

snip.ota2_example-CYW943907AEVAL1F ota2_image download_apps download run

Note:  这部分编译ota2_example ,下载到板子中并重启运行。

3. 下面是测试步骤：

  3.1  下载完成后你会发现ota2_example 跑的是hibernation的测试程序， 这个和我们的OTA2测试无关。

  3.2   先按住板子的user_2 键， 再按reset， 五秒以后松开，这个顺序很重要，"WICED Soft AP"程序会进入ota_extract , 并且创建一个SOFT_AP，

          我这边使用的是代码中自带的"WICED Soft AP"  , log 如下：

Hi, I'm the OTA2 extraction app (ota2_extract).

Starting WICED vWiced_006.002.001.0002

Platform CYW943907AEVAL1F initialised

Started ThreadX v5.8

Initialising NetX_Duo v5.10_sp3

Creating Packet pools

WLAN MAC Address : A4:08:EA:22:33:44

WLAN Firmware    : wl0: May 15 2018 19:39:17 version 7.15.168.114 (r689934) FWID 01-d6f88905

WLAN CLM         : API: 12.2 Data: 9.10.74 Compiler: 1.31.3 ClmImport: 1.36.3 Creation: 2018-05-15 19:33:15

SoftAP start, AP name: WICED Soft AP

IPv4 network ready IP: 192.168.10.1

Setting IPv6 link-local address

IPv6 network ready IP: FE80:0000:0000:0000:A608:EAFF:FED9:C9A4

     3.3 PC 加入到"WICED Soft AP" 这个AP， 并且在浏览器中输入192.168.10.1 ，得到如下的界面，

           注意在choose file中选择build\snip.apsta-CYW943907AEVAL1F\OTA2_image_file.bin, 然后点击升级就可以。

           升级完成后会自动reset，运行就会是apsta的程序了。

Scope:

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.

Summary:

   We already provided a good document for how to use DCT functions, this topic here is just to have a simple implement.

    My test and description are based on 43907 board.

• What is DCT

The content was described in the document, just copy it here. The DCT stores System and Application data persistently so that the device can use the information between power cycles. The layout of the data is extremely important,and may change between SDKs.

• DCT Layout

     Normal DCT area

     # DCT1

     NORMAL_IMAGE_DCT_1_AREA_BASE   := 0x00008000   #  16k  (0x00004000)    

     # DCT2

     NORMAL_IMAGE_DCT_2_AREA_BASE   := 0x0000C000   #  16k  (0x00004000)

     OTA2 DCT area

     OTA2_IMAGE_APP_DCT_SAVE_AREA_BASE    := 0x00208000  # 16k  0x00004000

     OTA2_IMAGE_CURR_DCT_1_AREA_BASE      := 0x0020d000        #  16k  0x00004000

     OTA2_IMAGE_CURR_DCT_2_AREA_BASE      := 0x00211000        #  16k  0x00004000

Talking to two DCT area:

There are two DCT areas defined in the FLASH, designated as DCT1 and DCT2. When there are changes to the DCT, we use these in a flip-flop arrangement, copying the “current” DCT to the opposite area with the changes requested, then indicating that the “new” area is the “current” area. Then we mark the “old” area as not in use. This ensures that if power is lost in any part of the update procedure, there is a viable DCT area upon power up.

Description in the function API:

*  Validate and return the current DCT address

* - determine the SDK version of the DCT

* - determine which DCT is valid and most recent

* - update the DCT to DCT_BOOTLOADER_SDK_CURRENT if needed

* - return section to the current DCT address

* - if both DCTs invalid, create a valid DCT to use

Because every time we flashed the image into DCT1 area, and maybe the new image will have different sdk_ver,

so we need a check and compare flow, the logics are:

1. Presume use_dct1=WICED_TRUE, then check if dct1 and dct2 area has valid sdk version.
2. If two areas have same SDK version, check initial write flag.
3. If dct1_sdk_version < dct2_sdk_version, make use_dct2 TRUE.
4. Below code is to backup DCT info to the other area before modification.

• DCT structure

If you read our DCT document in detail, you will find below structure is implemented and modified along with the SDK release.  DCT structure will be divided into three areas:

1. From dct_header to dct_version, DO NOT MOVE.
2. From the end of dct_version to the end of platform_dct_data_t, it is for handling additional requests. 
3. The area after the end of platform_dct_data_t, it should be

DCT_APP_SECTION that is used often in different applications.

wiced_result_t wiced_dct_write( const void* data, dct_section_t section, uint32_t offset, uint32_t data_length )

    /*

     * There are 3 parts to updating the data (other than platform_dct_header_t and platform_dct_version_t which

     * are handled in the function wiced_dct_finish_new_dct() above)

     * 1) Data before the (section_start + offset) of the new data

*      A) Some new data is between dct_header and dct_version

*      B) Some new data is between dct_version and the end of platform_dct_data_t

*      C) Some new data is after platform_dct_data_t

     * 2) the new data (section_start + offset) size: data_length

     *      A) Some new data is between dct_header and dct_version

     *      B) Some new data is between dct_version and the end of platform_dct_data_t

     *      C) Some new data is after platform_dct_data_t

     * 3) Data after the (section_start + offset+ data_length) of the new data, up to the end of PLATFORM_DCT_COPY1_SIZE

     *      A) Some new data is between dct_header and dct_version

     *      B) Some new data is between dct_version and the end of platform_dct_data_t

     *      C) Some new data is after platform_dct_data_t

     *

     * The code here is generic enough to handle all three cases without having to be maintained  B^)

     *

     */

If you have interests, please add more logs and test if the logic can match all your requests, and check if there exist bugs, thanks.

• Two ways to be familiar with DCT usages.

          One is command_console:    

          Add below define into the makefile of the application like apsta.mk;

Add include in the file command_console_commands.h:

Add to COMMAND table:

After compiling and download we can get the results:

The other is DCT_read_write APP:

snip.dct_read_write-CYW943907AEVAL1F-debug download download_apps

we have very detailed instructions in the released sdk also, the name is

/43xxx_Wi-Fi/doc/WICED-DCT.pdf

Introduction

The WLAN(802.11b/g/n), Bluetooth and Zigbee transmissions occur in the unlicensed ISM (The industrial, Scientific, and Medical) radio bands of 2.4GHz. Although they are modulated with different modulation schemes (FHSS for BT and DSSS/OFDM for WLAN), interference is bound to occur when the transmitting antennas are collocated. BT could hop into the WLAN band resulting in an exponential backoff before retransmission of packets. This degrades the performance of both BT as well as WLAN. Collaborative coexistence techniques remedies this issue by passing the channel map information from the WLAN module to the BT device.

This blog gives a brief description about the Cypress Proprietary Collaborative coexistence interface known as SECI (Serial Enhanced Coexistence Interface) and enabling it using cypress WLAN and Bluetooth devices

SECI uses the UART core(commonly named as GCI UART) to transmit ECI data. 64-bit coexistence data could be exchanged between WLAN and BT. As a result, a lot more information is passed on between the devices compared to its counterparts i.e. 3-wire and 4-wire coexistence. A refresh routine runs, that resyncronizes the devices upon waking from powersave.

The following is a logical diagram of SECI between two devices.

How to enable SECI in WLAN

Steps involved and their descriptions:

• Modify the LSB(bit[0]) of  boardflags parameter in the NVRAM file.

To enable 2-wire(SECI) coexistence, set the last bit(bit[0]) as 1.

Eg: if boardflags=0x10010000   ->  boardflags=0x10010001

How to enable SECI in Bluetooth side

Adding the API wiced_bt_coex_enable() in the application, enables the SECI in BT device.

Frequently Asked Questions

Is there a concept of AFH in collaborative coexistence?

The Adaptive Frequency Hop information is not passed back to WLAN, rather WLAN module passes information on current WLAN transmit channels. BT marks them as ‘bad’ and updates the channel map.

What information is exchanged?

Timeout parameters(egACL,SCO timeout limits, Powersave/idle times, Medium Request/Grant times) ,

Channel bitmap,

Priority of WLAN/BT activity bitmap, etc. are the some of the information that are exchanged.

Can the priorities be changed?

The priorities cannot be changed. It is hardcoded.

Generally, the highest priority goes to Audio/Video/BLE/hid transfer. File transfer has the least activity.

Configuring sLNA or dLNA?

Cannot be changed dynamically even though NVRAM parameters exists as it in Hardware.

What happens during WiFi powersave?

During Wifi powersave, all the requests from Bluetooth are given full grant. This is applicable for both sLNA and dLNA. Once WiFi comes out of powersave, it runs a refresh request to notify BT that it is awake. This restarts all the coex polls between WiFi and BT.

This blog discusses debugging of the default iot_mqtt_demo(MACRO: CONFIG_MQTT_DEMO_ENABLED) application in aws_demo project in WICED Studio 6.4 using AFR. The process is very similar to debugging in WICED Studio 6.4(non AFR) with some modifications in the debug configurations.

Steps to debug are:

1.  Remove the run flag from the default make target given for aws_demo

demo.aws_demo-CYW954907AEVAL1F-FreeRTOS-LwIP HOST_OS=Win32 download

2. Build the application by double clicking the make target.

3. Currently RTOS thread resolve during debug is not supported for AFR in WICED Studio.  As a work-around, open <wiced_studio_path>\43xxx_Wi-Fi\tools\OpenOCD\BCM4390x.cfg in a file editor and go to the line that has:

$_TARGETNAME configure -rtos auto -rtos-wipe

Remove “-rtos auto” from that line and save the file.

4. Open Run> debug_configurations or click the drop down button next to debug on toolbar and choose debug_configurations

5. Under GDB hardware Debugging, right-click on "43xxx_Wi-Fi_Debug_Windows” and click “Duplicate”. Change the name in the top of the window to “AFR Debug” or any other name you prefer.

6. In the “Main tab”

     6.1 click Browse under Project and select “aws_demos” project.

     6.2 Next, under C/C++ Application click "Search Project", select "last_built.elf" and click OK. Make sure it points to the last_built.elf of amazon-freertos. The location  is <afr_installation_path>\amazon-freertos\vendors\cypress\WICED_SDK\build\eclipse_debug\last_built.elf

7. Go to debugger tab and make sure the GDB command is pointing to the tools directory of your WICED SDK.

8. Apply the changes in debug configurations and click on debug. If you have connected the board and everything goes well, the debugger will start up and will pause execution in the start_GCC.S file.

9. You can open main.c and put a breakpoint at the line int main(void ) by double clicking on the left of the line or by right-clicking and selecting Toggle Breakpoint. (A check in front of the breakpoint shows that its an active breakpoint)

Click on the resume button to resume the execution of code and stopping on the next breakpoint. You can also use step in/over commands to step through your application.

Please note that if you wait indefinitely on a breakpoint inside a thread with a network connection it has a larger chance of getting disconnected. So, stopping execution while there is an active connection should be used sparingly.

Note that we have not modified the make target with the “-debug” flag that we usually use with other WICED Studio projects. The downside of not using -debug is that some variables may be optimized away.

Introduction

The following blog demonstrates a setup for conducting throughput test with coexistence enabled. The results of the conducted tests are also included thereby demonstrating the advantages of using coexistence. 2-wire SECI is used in this test for exchanging coexistence data among the two Cypress chips. More about SECI could be found in the following link: Overview of SECI.

The applications and the platforms used for throughput test are :

1. Iperf application running in CYW943907WAE4
2. Le_COC throughput application running in CYW20719Q40EVB_01(attached)

Connections

The diagram below depicts the pins and connections between the two boards:

Setting up CYW20719Q40EVB_01:

Any of the available(pins that are brought out in the platform) LHL GPIO pins can be configured to function as SECI. The LHL GPIOs WICED_P10 and WICED_P06(mapped to A0 and D8 respectively on CYW20719Q40EVB_01 ) are used as BT_SECI_OUT and BT_SECI_IN respectively in the attached BT throughput application.

To configure the LHL GPIOs as SECI, the following API is used:

wiced_bt_gpio_select_status_t wiced_hal_gpio_select_function(wiced_bt_gpio_numbers_t pin, wiced_bt_gpio_function_t function);

Eg: for configuring the LHL GPIOs, WICED_P10 and WICED_P06 as BT_SECI_OUT and BT_SECI_IN

wiced_hal_gpio_select_function(WICED_P10 , WICED_GCI_SECI_OUT);

wiced_hal_gpio_select_function(WICED_P06 ,WICED_GCI_SECI_IN );

And finally to enable coexistence in BT, the following API is used:

wiced_result_t wiced_bt_coex_enable( uint32_t seci_baud_rate );

Seci baud rate can be set to a maximum of 4M. In the attached example application, a baudrate of 3M is used.

Eg:

wiced_bt_coex_enable(3000000);

The following code pic depicts the usage of the above mentioned APIs:

Finally flash the application on the BLE GATT server( CYW20719Q40EVB_01 ), and connect the device to a BLE client. CySmart BLE 4.2 USB dongle was used as the client in this throughput test. Make sure to enable notifications from the server, in the client using the CySmart application.

Setting up CYW943907WAE4 :

Change the last bit/LSB of boardflags parameter in the nvram.txt to 1.

Each boardflags parameter is 32 bit wide. The LSB corresponds to switching the BTCOEX.

Eg;

Boardflag=0x0a0 => boardflags = 0x0a1

Following commands were used to setup the iperf in the AP and STA.

AP as UDP client(tx):

wl mpc 0

wl up

wl frameburst 1

start_ap tput open 0102 6 255.255.255.0 192.168.1.100

iperf -c 192.168.1.101 -u -i1 -t10 -w8m -b10m

AP as TCP client(tx):

iperf -c 192.168.1.101 -i1 -t10 -w8m

STA as UDP  server(rx):

wl mpc 0

wl up

join tput open 0102 192.168.1.101 255.255.255.0 192.168.1.100

iperf -s -u -i1 -8k

STA as TCP  server(rx):

iperf -s -i1 -8k

Finally throughput results here:

BLE and wifi thoughput without coexistence

UDP and TCP without BT interference and coex disabled

wifi data without BT interference and coex enabled

UDP throughput without BLE interference

[ ID] Interval       Transfer     Bandwidth        Jitter Lost/Total Datagrams

[  0] 0.0- 1.0 sec  1.20 MBytes  10.0 Mbits/sec   0.918 ms 0/  853 (0%)

[  0] 1.0- 2.0 sec  1.18 MBytes  9.93 Mbits/sec   0.949 ms 6/  850 (0.71%)

[  0] 2.0- 3.0 sec  1.19 MBytes  9.96 Mbits/sec   1.210 ms 2/  849 (0.24%)

[  0] 3.0- 4.0 sec  1.19 MBytes  10.0 Mbits/sec   0.982 ms 0/  852 (0%)

[  0] 4.0- 5.0 sec  1.19 MBytes  9.95 Mbits/sec   0.984 ms 3/  849 (0.35%)

[  0] 5.0- 6.0 sec  1.19 MBytes  9.97 Mbits/sec   1.407 ms 2/  850 (0.24%)

[  0] 6.0- 7.0 sec  1.18 MBytes  9.89 Mbits/sec   1.526 ms 4/  845 (0.47%)

[  0] 7.0- 8.0 sec  1.19 MBytes  9.95 Mbits/sec   1.005 ms 10/  856 (1.2%)

[  0] 8.0- 9.0 sec  1.19 MBytes  10.0 Mbits/sec   1.134 ms 0/  850 (0%)

[  0] 9.0-10.0 sec  1.19 MBytes  9.97 Mbits/sec   0.790 ms 3/  851 (0.35%)

[  0] 0.0-10.0 sec  11.9 MBytes  9.95 Mbits/sec   1.179 ms 31/ 8507 (0.36%)

TCP throughput without BLE interference and coex disabled

[  0]  0.0- 1.0 sec  1.01 MBytes  8.47 Mbits/sec

[  0]  1.0- 2.0 sec  1.12 MBytes  9.36 Mbits/sec

[  0]  2.0- 3.0 sec  1020 KBytes  8.36 Mbits/sec

[  0]  3.0- 4.0 sec   947 KBytes  7.76 Mbits/sec

[  0]  4.0- 5.0 sec   859 KBytes  7.04 Mbits/sec

[  0]  5.0- 6.0 sec  1.11 MBytes  9.31 Mbits/sec

[  0]  6.0- 7.0 sec  24.4 KBytes   200 Kbits/sec

[  0]  7.0- 8.0 sec  14.3 KBytes   117 Kbits/sec

[  0]  8.0- 9.0 sec  9.98 KBytes  81.8 Kbits/sec

[  0]  9.0-10.0 sec  4.28 KBytes  35.0 Kbits/sec

[  0]  0.0-10.8 sec  6.05 MBytes  4.70 Mbits/sec

UDP throughput with BLE interference and coex disabled

[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams

[  0]  0.0- 1.0 sec   680 KBytes  5.57 Mbits/sec   4.734 ms  166/  640 (26%)

[  0]  1.0- 2.0 sec   111 KBytes   906 Kbits/sec   2.146 ms   41/  118 (35%)

[  0]  2.0- 3.0 sec  1.44 KBytes  11.8 Kbits/sec  74.137 ms   30/   31 (97%)

[  0]  3.0- 4.0 sec   375 KBytes  3.07 Mbits/sec   1.105 ms    0/  261 (0%)

[  0]  4.0- 5.0 sec   996 KBytes  8.16 Mbits/sec   3.488 ms   25/  719 (3.5%)

[  0]  5.0- 6.0 sec   291 KBytes  2.39 Mbits/sec   9.384 ms  283/  486 (58%)

[  0]  6.0- 7.0 sec   502 KBytes  4.12 Mbits/sec   6.382 ms    0/  350 (0%)

[  0]  7.0- 8.0 sec   601 KBytes  4.93 Mbits/sec   2.328 ms    5/  424 (1.2%)

[  0]  8.0- 9.0 sec  1.26 MBytes  10.5 Mbits/sec   0.854 ms    4/  901 (0.44%)

[  0]  0.0-10.0 sec  5.86 MBytes  4.94 Mbits/sec   1.252 ms  555/ 4736 (12%)

Observable packet drops seen in Wifi due to interference from  BLE

TCP throughput with BLE interference

[  0] 0.0- 1.0 sec  29.9 KBytes   245 Kbits/sec

[  0] 1.0- 2.0 sec   369 KBytes  3.03 Mbits/sec

[  0] 2.0- 3.0 sec   605 KBytes  4.96 Mbits/sec

[  0] 3.0- 4.0 sec  21.0 KBytes   172 Kbits/sec

[  0] 4.0- 5.0 sec   247 KBytes  2.03 Mbits/sec

[  0] 5.0- 6.0 sec   490 KBytes  4.01 Mbits/sec

[  0] 6.0- 7.0 sec  9.98 KBytes  81.8 Kbits/sec

[  0] 7.0- 8.0 sec  3.82 KBytes  31.3 Kbits/sec

[  0] 8.0- 9.0 sec  1.89 KBytes  15.5 Kbits/sec

[  0] 9.0-10.0 sec  8.55 KBytes  70.1 Kbits/sec

[  0] 10.0-11.0 sec  0.00 Bytes 0.00 bits/sec

[  0] 11.0-12.0 sec  2.85 KBytes 23.4 Kbits/sec

[  0] 12.0-13.0 sec  1.43 KBytes 11.7 Kbits/sec

[  0] 13.0-14.0 sec  4.28 KBytes 35.0 Kbits/sec

[  0] 0.0-14.3 sec  1.76 MBytes  1.03 Mbits/sec

UDP throughput with coex enabled

[  0] 0.0- 1.0 sec  1.20 MBytes  10.0 Mbits/sec   1.067 ms 0/  853 (0%)

[  0] 1.0- 2.0 sec  1.12 MBytes  9.36 Mbits/sec   0.895 ms 2/  798 (0.25%)

[  0] 2.0- 3.0 sec  1024 KBytes  8.38 Mbits/sec   1.135 ms 21/  734 (2.9%)

[  0] 3.0- 4.0 sec  1.26 MBytes  10.5 Mbits/sec   0.842 ms 2/  898 (0.22%)

[  0] 4.0- 5.0 sec  1.16 MBytes  9.76 Mbits/sec   0.985 ms 8/  838 (0.95%)

[  0] 5.0- 6.0 sec  1002 KBytes  8.21 Mbits/sec   0.952 ms 10/  708 (1.4%)

[  0] 6.0- 7.0 sec  1.40 MBytes  11.7 Mbits/sec   0.944 ms 28/ 1025 (2.7%)

[  0] 7.0- 8.0 sec  1.20 MBytes  10.1 Mbits/sec   1.131 ms 10/  865 (1.2%)

[  0] 8.0- 9.0 sec  1.09 MBytes  9.17 Mbits/sec   1.257 ms 4/  784 (0.51%)

[  0] 9.0-10.0 sec  1.24 MBytes  10.4 Mbits/sec   1.130 ms 25/  912 (2.7%)

[  0] 0.0-10.0 sec  11.6 MBytes  9.75 Mbits/sec   1.435 ms 111/ 8417 (1.3%)

TCP throughput with coex enabled

[  0] 0.0- 1.0 sec  3.55 MBytes  29.7 Mbits/sec

[  0] 1.0- 2.0 sec  3.61 MBytes  30.3 Mbits/sec

[  0] 2.0- 3.0 sec  3.46 MBytes  29.1 Mbits/sec

[  0] 3.0- 4.0 sec  3.05 MBytes  25.6 Mbits/sec

[  0] 4.0- 5.0 sec  16.4 KBytes   134 Kbits/sec

[  0] 5.0- 6.0 sec  2.14 KBytes  17.5 Kbits/sec

[  0] 6.0- 7.0 sec  2.02 MBytes  16.9 Mbits/sec

[  0] 7.0- 8.0 sec  2.93 MBytes  24.6 Mbits/sec

[  0] 8.0- 9.0 sec  1.42 MBytes  11.9 Mbits/sec

[  0] 9.0-10.0 sec  3.47 MBytes  29.1 Mbits/sec

[  0] 0.0-10.0 sec  23.5 MBytes  19.7 Mbits/sec

BLE throuhgput when coex not enabled

BLE througput with coex enabled

Inference:

Given the low priority setting for the BT custom profile(for client-server notification), the throughput saw a observable improvement in WiFi side and at the same time the BT side experienced a heavy throughput loss.