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:

Presume use_dct1=WICED_TRUE, then check if dct1 and dct2 area has valid sdk version.

If two areas have same SDK version, check initial write flag.

If dct1_sdk_version < dct2_sdk_version, make use_dct2 TRUE.

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:

From dct_header to dct_version, DO NOT MOVE.

From the end of dct_version to the end of platform_dct_data_t, it is for handling additional requests.

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 :

Iperf application running in CYW943907WAE4

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.

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.

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.

The cryptography core in CYW43907, also known as crypto, is a dedicated hardware core present in the applications processor. It is used for performing cryptographic operations such as encryption and hashing in dedicated engines. The following operations are supported:

The hwcrypto is used in mbedTLS cryptographic operations as well as secure boot. By default, hwcrypto is enabled for mbedTLS operations. The macro PLATFORM_HAS_HW_CRYPTO_SUPPORT is used for enabling hwcrypto for mbedTLS and it is defined in BCM4390x.mk as shown below:

The above macros are used for enabling hwcrypto APIs defined in files marked with _alt.c in mbedtls_open/library. For instance, when MBEDTLS_AES_ALT is enabled, the APIs present in aes_alt.c are enabled which would call the driver functions such as hw_aes_crypt() in platform_tiny_crypto.c.

An SPU message is processed by the crypto core. Its contains the following:

MAX_DMA_BUFFER_SIZE: This is the maximum size of DMA descriptor buffer which is 16kB. If the DMA payload size exceeds MAX_DMA_BUFFER_SIZE, it is split into chunks of MAX_DMA_BUFFER_SIZE. This is implemented in hwcrypto_split_dma_data() called in populate_input_descriptors().

This blog discusses the different binaries that are downloaded in CYW943907AEVAL1F EVK when the board is programmed using WICED SDK. This blog also addresses the procedure of creating a single binary suitable for manufacturing. Please note that the manufacturing image procedure is explained for ota2 compatible image. The same method can be followed to create a similar image for generic case(non OTA2).

WICED FRAMEWORK:

The different binaries needed for programming a CYW943907AEVAL1F EVK are

1. Bootloader

2. DCT

3. APPS LUT

4. FILESYSTEM

5. APPLICATION(There can be multiple applications APP0, APP1, APP2)

During a normal build process, the files which are downloaded can be viewed by including VERBOSE=1 in the make target. The downloaded files from the build log are shown below: