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