Skip navigation
Home > All Places > WICED Studio Wi-Fi/Combo > WICED Studio Wi-Fi/Combo Forums > Blog > 2019 > March
2019

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 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:

image1.png

 

 

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:

bt_coex_code.png

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

BT_activity_without_coex.png

BLE througput with coex enabled

 

BT_activity_with _coex.png

 

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:

 

Encryption:
AES module which supports CBC, ECB, CTR, CFB modes
DES module to support DES and 3DES encryption with ECB and CBC modes

 

Hashing:
MD5, SHA1, SHA224, and SHA256 to support HMAC

 

Using hardware crypto in WICED

 

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:

GLOBAL_DEFINES +=  PLATFORM_HAS_HW_CRYPTO_SUPPORT
$(NAME)_SOURCES += platform_crypto.c

To disable hwcrypto, the above statements should be commented out. The PLATFORM_HAS_HW_CRYPTO_SUPPORT effectively enables the following macros in mbedtls/config.h:

MBEDTLS_AES_ALT
MBEDTLS_DES_ALT
MBEDTLS_MD5_ALT
MBEDTLS_SHA256_ALT
MBEDTLS_SHA1_ALT

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:

 

           INPUT HEADER                       OUTPUT HEADER

     +-------------------------+         +------------------------+

     | Message Header (MH )    |         | Message Header (MH)    |

     +-------------------------+         +------------------------+

     | Extended Header (EH)    |         | Extended Header (EH)   |

     +-------------------------+         +------------------------+

     | SCTX Header 0  (SCTX0)  |         | Output data : Payload  |

     +-------------------------+         +------------------------+

     | SCTX Header 1  (SCTX1)  |         | Status                 |

     +-------------------------+         +------------------------+

     | SCTX Header 2  (SCTX2)  |

     +-------------------------+

     | BufferDescriptor (BDESC)|

     +-------------------------+

     | Buffer Data (BD)        |

     +-------------------------+

     | Input data : Payload    |

     +-------------------------+

     | Status                  |

     +-------------------------+

 

Where SCTX is the security context.

 

The DMA descriptors to SPU-M have the following format:

     INPUT DMA Descriptors                           OUTPUT DMA Descriptors

    +--------------------------+                    +--------------------------+

    | Header                   |                    | Header                   |

    | (MH + EH + SCTX0 + SCTX1 |                    | (MH + EH + BDA )         |

    |  SCTX2 + SCTX3)          |                    +--------------------------+

    +--------------------------+                    | start_aligned_buffer@    |

    | Payload 1                |                    | (PLATFORM_L1_CACHE_BYTES |

    | (MAX_DMA_BUFFER_SIZE)    |                    +--------------------------+

    +--------------------------+                    | Payload 1                |

    | Payload 2*               |                    | (MAX_DMA_BUFFER_SIZE)    |

    | (MAX_DMA_BUFFER_SIZE)    |                    +--------------------------+

    +--------------------------+                    | Payload 2*               |

    | Payload 3*               |                    | (MAX_DMA_BUFFER_SIZE)    |

    | (MAX_DMA_BUFFER_SIZE)    |                    +--------------------------+

    +--------------------------+                    | Payload 3*               |

    | Payload 4*               |                    | (MAX_DMA_BUFFER_SIZE)    |

    | (MAX_DMA_BUFFER_SIZE)    |                    +--------------------------+

    +--------------------------+                    | Payload 4*               |

    | STATUS                   |                    | (BYTES_IN_WORD)          |

    | (BYTES_IN_WORD)          |                    +--------------------------+

    +--------------------------+                    | end_aligned_buffer@      |

                                                    | (MAX_DMA_BUFFER_SIZE)    |

                                                    +--------------------------+

                                                    | HASH_OUTPUT#             |

                                                    | (BYTES_IN_WORD)          |

                                                    +--------------------------+

                                                    | STATUS                   |

                                                    | (BYTES_IN_WORD)          |

                                                    +--------------------------+

    *
    * * : Payload2/3/4 only required if Payload1/2/3 > MAX_DMA_BUFFER_SIZE
    * # : Hash output present only if cmd.hash_output is Not NULL
    * @ : Start/end aligned buffer is needed to ensure that the Start address and size of DMA is
    *     PLATFORM_L1_CACHE_BYTES aligned
    */

The following macros are defined in platform_tiny_crypto.c:

 

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

 

MAX_TX_DMADESCRIPTOS: This is the maximum size of input DMA descriptors as shown in the format above. Its value is 1 (header) +  4 (payload) + 1 (padded hash input) + 1 (status)

 

MAX_RX_DMADESCRIPTOS: This is the maximum size of output DMA descriptors as shown in the format above. Its value is 1 (header) +  4 (payload) + 2 (aligned payload buffers) + 1 (hashoutput) + 1 (status)

 

HWCRYPTO_MAX_PAYLOAD_SIZE: This is the maximum hwcrypto payload size that the SPU-M can handle at a time during cryptographic operation.

 

Other macros specific to encryption and hashing have been listed in crypto_api.h.

 

A sample WICED code for testing AES-CBC using hwcrypto has been attached.

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:

1. DCT

Downloading DCT ... build/<snip_name>-CYW943907AEVAL1F/DCT.bin @ SFLASH_DCT_LOC=0x00008000

2. The Bootloader file is:

build/waf.bootloader-NoOS-NoNS-CYW943907AEVAL1F-P103-SoC.43909/binary/waf.bootloader-NoOS-NoNS-CYW943907AEVAL1F-P103-SoC.43909.trx.bin

3. Filesystem is created with

./tools/common/Win32/mk_wicedfs32 build/<snip_name>-CYW943907AEVAL1F/filesystem.bin build/<snip_name>-CYW943907AEVAL1F/resources/Staging/

and downloaded

Downloading resources filesystem ... build/<snip_name>-CYW943907AEVAL1F/filesystem.bin at sector 17  size <filesystem_size>...

4. Downloading Application

Downloading APP0 build/<snip_name>-CYW943907AEVAL1F/binary/<snip_name>-CYW943907AEVAL1F.stripped.elf @ sector <filesystem_start_address + filesystem_size> address xxx size <filesystem_size>...

5. APPS LUT

Downloading apps lookup table in wiced_apps.mk ... build/<snip_name>-CYW943907AEVAL1F/APPS.bin @ 0x00010000 size

 

How are the addresses determined for programming the binaries/files?

>> The memory map is defined in <WICED- SDK>\43xxx_Wi-Fi\platforms\CYW943907AEVAL1F\normal_image_defines.mk

The starting address of filesytem is given as:

In /43xxx_Wi-Fi/platforms/CYW943907AEVAL1F/normal_image_defines.mk,

NORMAL_IMAGE_APPS_AREA_BASE := 0x00011000 i.e, 69632 d

 

In /43xxx_Wi-Fi/WICED/platform/MCU/BCM4390x/BCM94390x_common.mk

APPS_START_SECTOR := $(shell $(PERL) $(SECTOR_NUMBER_SCRIPT) $(NORMAL_IMAGE_APPS_AREA_BASE) $(SECTOR_SIZE))

 

Hence APPS_START_SECTOR=69632/4096 = 17

 

The starting address of application stripped.elf is obtained by adding the filesystem size to APPS_START_SECTOR.

Kindly check the BUILD_APPS_RULES in 43xxx_Wi-Fi/tools/makefiles/wiced_apps.mk for understanding the computation of starting sectors.

 

MANUFACTURING IMAGE:

The manufacturing image is a single image suitable for download during manufacturing.

WICED has implemmenttaion for creating manufacturing image suitable for OTA2. It follows the memory map defined in 43xxx_Wi-Fi\platforms\CYW943907AEVAL1F\ota2_image_defines.mk

The image is created using "ota2_manuf_image" in the make target.

 

How is the manufacturing image created and which files are included in it?

>> Please look for ota2_manuf_image target in 43xxx_Wi-Fi\tools\makefiles\wiced_apps.mk

First a manufacturing config file is created.

$(QUIET)$(call WRITE_FILE_CREATE, $(OTA2_IMAGE_MANUFACTURING_CONFIG_FILE) ,$(OTA2_IMAGE_BOOTLOADER_START) build/$(BOOTLOADER_TARGET)/binary/$(BOOTLOADER_TARGET).trx.bin)

The config file is than appended with information of other required binaries. One such example is:

$(QUIET)$(call WRITE_FILE_APPEND, $(OTA2_IMAGE_MANUFACTURING_CONFIG_FILE) ,$(OTA2_IMAGE_FACTORY_RESET_AREA_BASE) $(OTA2_IMAGE_FACTORY_RESET_BIN_FILE))

The config file is then passed to a tool which creates the image. The image is filled with 0xFF for unused parts of the FLASH

$(shell $(PERL) $(CREATE_FLASH_IMAGE_TOOL) $(call CONV_SLASHES,$(OTA2_IMAGE_MANUFACTURING_CONFIG_FILE)) $(call CONV_SLASHES,$(OTA2_IMAGE_MANUFACTURING_BIN_FILE)))

 

The  $(CREATE_FLASH_IMAGE_TOOL) is located @43xxx_Wi-Fi\tools\common\<OS>\mk_wiced_ota2_image32.exe

Filter Blog

By date:
By tag: