Skip navigation
Home > All Places > WICED Studio Wi-Fi/Combo > WICED Studio Wi-Fi/Combo Forums > Blog
1 2 3 Previous Next

WICED Studio Wi-Fi/Combo Forums

120 posts

    在我们释放的文档中已经有比较详细的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.

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.

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

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

CONSOLE_NO_P2P :=1

CONSOLE_DISABLE_WPS_COMMANDS := 1

CONSOLE_DISABLE_TRACEX_COMMANDS := 1

 

GLOBAL_DEFINES     += CONSOLE_DISABLE_ENTERPRISE_COMMANDS

$(NAME)_DEFINES    += CONSOLE_DISABLE_WPS_COMMANDS

$(NAME)_DEFINES    += CONSOLE_DISABLE_TRACEX_COMMANDS

$(NAME)_DEFINES    += CONSOLE_DISABLE_MALLINFO_COMMANDS

       GLOBAL_DEFINES += DISABLE_WIFI_AP_INTERFACE \

                       WICED_CONFIG_DISABLE_SSL_SERVER \

                       WICED_CONFIG_DISABLE_DTLS \

                       WICED_CONFIG_DISABLE_ENTERPRISE_SECURITY \

                       WICED_CONFIG_DISABLE_DES \

                       WICED_CONFIG_DISABLE_ADVANCED_SECURITY_CURVES \

                       WICED_DISABLE_WATCHDOG

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

$(NAME)_DEFINES    += CONSOLE_INCLUDE_WIFI_LIMITED_SET_COMMANDS

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

 

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

 

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

 

    1. Add

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

under the #define WIFI_COMMANDS_LIMITED_SET \

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

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

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

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

{

wwd_result_t result = wwd_wifi_set_down();

 

if (result != WWD_SUCCESS)

{

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

}

 

    return result;

}

 

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

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

{

wwd_result_t result;

uint32_t bi = atoi(argv[1]);

 

result = wwd_wifi_set_ioctl_value(WLC_SET_BCNPRD, bi, WWD_STA_INTERFACE);

 

if(result != WWD_SUCCESS)

{

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

}

 

          return result;

 

}

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

 

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

 

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

   目标:

    主要去了解wiced中关于DEFINED_APP_DCT的用法, 在我们的释放的文档中,有一节描述,名字叫做APPLICNATION DCT data 有一句话这样描述:

    The DCT system allows for Applications to add Data to the end of the DCT area which will be maintained when the DCT is updated。

    我们释放的wiced sdk中的文档有不错的描述, 文档名字是:WICED-DCT.pdf

 

步骤:

     这是其中的描述, 3.1 3.4.1 都是描述如何使用application dct area

 

 

如上我们可以看到几个关键字和用法:

  a. Wiced_dct_read_lock, wiced_dct_read_unlock 必须成对使用, 不然会有memory leak.

  b. DCT_APP_SECTION, 是专用的名字,用来访问这部分区域。

  如下图中所显示,

     DCT_APP_SECTION 部分的offset是整个platform_dct_data_t, 表示这部分区域紧跟着后面,但是不会超过整个dct 分配的大小,

  比如16k-sizeof(platform_dct_data_t) 的大小。

 

 

测试开始:

  1. 我将会在apsta这个应用中按照文档来做一个测试来判定是否有效:

   搜索下, 发现我们的很多应用中都已经采用了这种方式:

 

2. 将dct_read_write_dct.c  dct_read_write_dct.h 直接拷贝到apsta的文件夹中,并且重命名为apsta_dct.c, apsta_dct.

    3.  Makefile 中添加编译:

4. 略作修改

5.添加调用的时候不要忘记头文件。

#include "apsta_dct.h"

6. log中查看是否有效:

7. 我们在结构体中添加了基本的类型,现在添加一个复杂结构体看是否有效。

将这段定义拷贝到新的dct.h中。

最后将几个结构体整合到一起就成了这样的情况, 所以只要按照我们的步骤就可以实现你想要的保存的信息:

 

测试成功了, 最后上传测试代码。

概要: 

   我们有四种方法在WICED中去设置wifi的mac地址, 这篇博客将展示如何通过这些方法去设置。 我的测试是基于

CYW954907AEVAL1F 这个开发板 。

 

  • 第一种:DCT mode:
  1. 1. app.mk中添加这个定义: GLOBAL_DEFINES     += MAC_ADDRESS_SET_BY_HOST
  2. App.mk是泛指,比如在apsta.mk 这样一个application中的定义。
    1. 2. 43xxx_Wi-Fi\generated_mac_address.txt

在前面的地址中修改如下红色重点的部分,可以看到mac地址修改成功。

#define NVRAM_GENERATED_MAC_ADDRESS "macaddr=00:A0:50:38:f6:35"

#define DCT_GENERATED_MAC_ADDRESS "\x00\xA0\x50\xe8\xf3\x48"

       #define DCT_GENERATED_ETHERNET_MAC_ADDRESS "\x00\xA0\x50\xe5\xf3\x47

 

  • 第二种 OTP mode
  1. 在相同的app.mk中屏蔽 //GLOBAL_DEFINES     += MAC_ADDRESS_SET_BY_HOST
  2. 需要点击clean 清楚掉编译文件,重新全部编译,看如下log,mac地址也被修改.

 

Starting WICED vWiced_006.002.001.0002

Platform CYW954907AEVAL1F initialised

Started ThreadX v5.8

Initialising NetX_Duo v5.10_sp3

Creating Packet pools

WLAN MAC Address : B8:D7:AF:4D:1D:D6

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

下面我们使用MFG 工厂测试模式去查看下OTP 区域内的MAC地址, 注意这边需要重新编译并且下载一个新的应用,此应用专门用于工厂模式测试,命令如下:

test.mfg_test-CYW954907AEVAL1F download download_apps run

比较下地址,这部分完全一样,可以证实这个地址是从OTP 区域内读出:

WLAN MAC Address : B8:D7:AF:4D:1D:D6

 

  • 第三种 在NVRAM中修改

43xxx_Wi-Fi\platforms\CYW954907AEVAL1F\board_revision\P101

     static const char wifi_nvram_image[] =

      "sromrev=11" "\x00"

      "vendid=0x14e4" "\x00"

      "devid=0x43d0" "\x00"

      "macaddr=00:A0:50:38:f6:35" "\x00"

 

  1. 一样需要屏蔽 //GLOBAL_DEFINES     += MAC_ADDRESS_SET_BY_HOST
  2. 全部clean,然后重新编译.
  3. 从结果来看MAC地址依然是: WLAN MAC Address : B8:D7:AF:4D:1D:D6

现在还没有找到那边可以将MAC地址固定在NVRAM 输出,所以假设OTP和NVRAM是有优先级的排列,如果OTP 区域存在有效的mac地址,那么NVRAM的将会被忽略。

  • 第四种 客户定制模式:
  1. 同样需要使能这个宏的定义,app makefile: GLOBAL_DEFINES     += MAC_ADDRESS_SET_BY_HOST
  2. 用户模式的话,需要在代码中添加修改:

在这个路径下的文件中做代码的改动,

43xxx_Wi-Fi\WICED\platform\MCU\BCM4390x\bcm4390x_platform.c

wwd_result_t host_platform_get_mac_address( wiced_mac_t* mac )

{

#ifndef WICED_DISABLE_BOOTLOADER

    wiced_mac_t* temp_mac;

    wiced_result_t result;

result = wiced_dct_read_lock( (void**)&temp_mac, WICED_FALSE, DCT_WIFI_CONFIG_SECTION, OFFSETOF(platform_dct_wifi_config_t, mac_address), sizeof(mac->octet) );

    if ( result != WICED_SUCCESS )

{

        return (wwd_result_t) result;

}

memcpy( mac->octet, temp_mac, sizeof(mac->octet) );

mac->octet[0]= 0x00;

mac->octet[1]= 0x11;

mac->octet[2]= 0x22;

mac->octet[3]= 0x33;

mac->octet[4]= 0x44;

mac->octet[5]= 0x55;

wiced_dct_read_unlock( temp_mac, WICED_FALSE );

#else

UNUSED_PARAMETER( mac );

#endif

    return WWD_SUCCESS;

}

 

Starting WICED vWiced_006.002.001.0002

Platform CYW954907AEVAL1F initialised

Started ThreadX v5.8

Initialising NetX_Duo v5.10_sp3

Creating Packet pools

WLAN MAC Address : 00:11:22:33:44:55

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

Console app

 

从结果看WifiMAC 地址被强制改成了我们想要的地址, 忽略了其他的设置。

 

This blog post discusses the procedure to create a new application in Amazon FreeRTOS(AFR).

The SHA1 for repository cloned for this blog post is dae010944f32b403acff8a5a888222da11b8b5a4.

Please follow the steps mentioned in Getting Started with the Cypress CYW943907AEVAL1F Development Kit - Amazon FreeRTOS to setup AFR for CYW943907EVAL1F or CYW54907AEVAL1F

We will be using the APIs provided in AFR for writing SCAN application in this blog.

 

Please follow the steps mentioned below for adding scan application in AFR:

1. We will be forking the AFR repository and will make changes in the forked repository. Visit the FreeRTOS github repository and fork the repo.

Download the repository:

git clone https://github.com/<user_name>/amazon-freertos.git

 

2. To get your repository structure as per the repository used for this blog, checkout the mentioned SHA1:

git checkout dae010944f32b403acff8a5a888222da11b8b5a4

The same steps might be valid for a newer version of AFR with minor changes.

3. You will see an aws_demos project in WICED when you import the aws_demos project.

Let us add the new application in demos directory of aws_demos. Go to the exact path of demos directory in your cloned repo: I have it in C:\afr\amazon-freertos\demos

Create a new folder named scan.

4. Place the attached files(cy_scan.h and cy_scan.c) in the scan folder.

5. The scan folder is kept at the absolute path but is not linked in the aws_demos project in WICED hence it will not appear in the demos directory in aws_demos project in WICED.

To establish a link,  open .project file of the project in text editor and add the link in <linkedResources> as follows:

        <link>

            <name>demos/scan/cy_scan.c</name>

            <type>1</type>

            <locationURI>BASE_DIR/demos/scan/cy_scan.c</locationURI>

        </link>

        <link>

            <name>demos/scan/cy_scan.h</name>

            <type>1</type>

            <locationURI>BASE_DIR/demos/scan/cy_scan.h</locationURI>

        </link>

6. Open the iot_demo_runner.h file and add the following two lines along with the other MACROS defined:

 

#elif defined (CONFIG_CY_SCAN_DEMO_ENABLED)

    #define DEMO_entryFUNCTION                              vStartScanDemo

 

The vStartScanDemo is written in cy_scan.c file.

7. Open the aws_demo_config.h file and enable the defined MACRO instead of CONFIG_MQTT_DEMO_ENABLED

#define CONFIG_CY_SCAN_DEMO_ENABLED

 

8. Open the application makefile(aws_demos/vendors/cypress/WICED_SDK/apps/demo/aws_demo/aws_demo.mk) and add the file names as follows:

Add the cy_scan.c file in $(NAME)_RESOURCES

     $(AMAZON_FREERTOS_PATH)demos/scan/cy_scan.c \

Add the cy_scan.h file in GLOBAL_INCLUDES

    $(AMAZON_FREERTOS_PATH)demos/scan \

 

9. Build the target by clicking on the provided make target

demo.aws_demo-CYW943907AEVAL1F-FreeRTOS-LwIP HOST_OS=Win32 download run

 

10. Open serial terminal and check the UART logs for scan result:

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

WICED currently has support for sflash from the following manufacturers.

  1. MACRONIX
  2. MICRON
  3. SST
  4. EON
  5. ISSI
  6. WINBOND
  7. CYPRESS

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

 

For ST based platforms:

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

    #define SFLASH_ID_MX25L8006E           ( (uint32_t) 0xC22014 )

    #define SFLASH_ID_MX25L1606E           ( (uint32_t) 0xC22015 )

    #define SFLASH_ID_MX25L6433F           ( (uint32_t) 0xC22017 )

    #define SFLASH_ID_MX25L12835F          ( (uint32_t) 0xC22018 )

    #define SFLASH_ID_MX25L25635F          ( (uint32_t) 0xC22019 )

    #define SFLASH_ID_MX25U1635F           ( (uint32_t) 0xC22535 )

    #define SFLASH_ID_MX66U51235F          ( (uint32_t) 0xC2253A )

    #define SFLASH_ID_SST25VF080B          ( (uint32_t) 0xBF258E )

    #define SFLASH_ID_EN25QH16             ( (uint32_t) 0x1C3015 )

    #define SFLASH_ID_ISSI25CQ032          ( (uint32_t) 0x7F9D46 )

    #define SFLASH_ID_N25Q512A             ( (uint32_t) 0x20BB20 )

    #define SFLASH_ID_ISSI25LP064          ( (uint32_t) 0x9D6017 )

    #define SFLASH_ID_N25Q064A             ( (uint32_t) 0x20BA17 )

    #define SFLASH_ID_W25Q64FV             ( (uint32_t) 0xEF4017 )

    #define SFLASH_ID_CY15B104Q            ( (uint32_t) 0x7F7F7F )

    +#define SFLASH_ID_N25Q128A             ( (uint32_t) 0x20BA18 )

 

    #define SFLASH_ID_DEFAULT              ( (uint32_t) 0x000000 )

 

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

 

   #define SFLASH_SIZE_1MByte                0x100000

   #define SFLASH_SIZE_2MByte                0x200000

   #define SLFASH_SIZE_32MByte               0x2000000

   #define SFLASH_SIZE_64MByte               0x4000000

   #define SFLASH_SIZE_512KByte              0x80000

   #define SFLASH_SIZE_16MByte               0x1000000

 

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

 

         device_id_to_flash_size_t sflash_device_id_size [SFLASH_ID_MAX_PARTS] =

         {

                { SFLASH_ID_MX25L8006E,  SFLASH_SIZE_1MByte   },

                { SFLASH_ID_MX25L1606E,  SFLASH_SIZE_2MByte   },

                { SFLASH_ID_MX25L25635F, SLFASH_SIZE_32MByte  },

                { SFLASH_ID_MX25U1635F,  SFLASH_SIZE_2MByte   },

                { SFLASH_ID_SST25VF080B, SFLASH_SIZE_1MByte   },

                { SFLASH_ID_EN25QH16,    SFLASH_SIZE_2MByte   },

                { SFLASH_ID_N25Q512A,    SFLASH_SIZE_64MByte  },

                { SFLASH_ID_CY15B104Q,   SFLASH_SIZE_512KByte },

                { SFLASH_ID_N25Q128A,    SFLASH_SIZE_16MByte  }

 

         };

 

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

 

 

For 4390x based platform

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

                  

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

       #ifdef SFLASH_SUPPORT_MICRON_PARTS

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

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

      #endif

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

             GLOBAL_DEFINES += SFLASH_SUPPORT_MICRON_PARTS

 

Debugging Notes:

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


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

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

Disclaimer: The attached demo code is developed to provide a reference to the customer, it has not been extensively tested. Also, it does not perform all the functionalities included in hello_client app available for Bluetooth devices in WICED SDK.

 

Introduction:

The Hello client demo app available for CYW20706, CYW20719 and CYW20735 in WICED SDK, is designed to connect and access services of the Hello sensor device. This post discusses about an example, which allows WiFi-BT Combo devices to act as a central device (client).

 

Procedure:

Extract the project in the attached zip file ble_hello_client.zip in /43xxx_Wi-Fi/apps/snip/snip/Bluetooth/ directory. Program the device using the ble_hello_client project. After programming, WICED device scans for the available Bluetooth devices. UUID and device name of the ble_hello_sensor project is already defined in application (ble_hello_client.c). WICED device recognizes the desired device and tries to connect to it, invoking the connection up callback.

 

Note that ble_hello_sensor should be running and advertising to test the client functionality. Both Combo and Bluetooth chips can be used for Hello sensor app. Be ensured that the UUID and device name of the Hello sensor device is correctly mentioned in Hello client app.

SUMMARY:

  We have some snip ,test codes in SDK release, this blog is showing how to use snip.dct_read_write, snip.apsta, snip.GPIO to finish one application. And the function is to join different AP by pressing user button. It will help you to understand how to join AP , how to read/write DCT area, be familiar with rule of GPIO operation. Test is based on Wiced 6.2.1.2 release on CYW954907AEVAL1F EVB.

 

MAIN WORK:

  1. STA join one AP, and ping , this is the APSTA from snip .
  2. Because CYW54907 has big internal flash and ram, so apsta includes COMMAN_CONSOLE function,

       you can type <status> to check the interface like below:

3. If you want to use command console ,really need big memory (2MB and above), and you need to enable it in makefile:

GLOBAL_DEFINES += INCLUDE_COMMAND_CONSOLE

If you want to use the DCT mac address, you need to enable it in makefile:

GLOBAL_DEFINES +=MAC_ADDRESS_SET_BY_HOST

Some other useful commands are showed here.

4. ADD user_1, user_2 GPIO test code into APSTA.

to find platform_gpio_buttons define in platform.c and platform.h

Below are some structure relationships in the code.

You will see real user_1, user_2 connections in the pdf circuit.

 

About user_1 and user_2 button initialization, these two pins are already set to INPUT_PULL_UP by default in the boot stage of the board,so you don’t need to initialize them again as a GPIO.

5.     Add DCT read code into APSTA.

  • Show notes about DCT usage
  • With the DCT in external FLASH, the second argument is ignored. For clarity, always use WICED_TRUE ---- This is for 54907 because DCT is in external flash.

      

  • wiced_dct_read_lock() and wiced_dct_read_unlock() need to be used with a couple.  But you do not need to call wiced_dct_read_lock() in order to write date to DCT.

    

  • DCT structure will be used by bootloader also , the sub-structure platform_dct_header_t, which is always at the start of the DCT area of the FLASH.
  • From SDK-3.7.0, it is possible to upgrade the DCT layout when doing SDK upgrading .
  • There are two DCT areas defined in the FLASH, designated as DCT1 and DCT2. we use this in a flip-flop arrangement. When need to update DCT area, we copy the “current” DCT to the opposite area , then indicate that “new” area is the “current” area. The “old ” area is viable DCT area.

 

    Below is the wifi config section printed:

 

6. Adding code to switch AP

  • IOCTL command description.
    • If you want to input “wl down” when DUT is in STA mode, call this function.

         

    • If you want to input “wl disassoc”, call this function

         

    • If you want to input an IOCTL command with value or not, please use below interface:

                 And it is better to add some wwd_wlan_status judge before jumping into  calling.

           

7. add all functions into apsta code:

    The steps are:

  1. to check the Button pressed status.
  2. to disassociate the AP.
  3. Network down.
  4. to write DCT to update the AP ssid which will be joined.
  5. to print the DCT updated.
  6. Network up, join the AP.

 

Reference:

Snip.apsta

Snip.GPIO

Snip.dct_read_write

WICED Device Configuration Table (DCT) Users Guide

cyw954907aeval1f.pdf

  • SUMMARY:

  We divide the SDK code into different module or library for specific function, and Hierarchical software design also is useful for the code maintenance. This blog is to show the log setting for different module.  Please see below architecture from SDK release document. Our aim is to print useful logs when issue happens,  upload one module picture from SDK release .

 

  • HOW TO Print LOGS
  1. To use “printf” directly, this is very convenient for the debug, but not easy to make a good management for the logs added. Some basic knowledge of print is in this link

https://fresh2refresh.com/c-programming/c-printf-and-scanf/

 

     #include <stdio.h>

     int main()

     {

        char ch = 'A';

        char str[20] = "fresh2refresh.com";

        float flt = 10.234;

        int no = 150;

        double dbl = 20.123456;                         

        printf("Character is %c \n", ch);

        printf("String is %s \n" , str);

        printf("Float value is %f \n", flt);

        printf("Integer value is %d\n" , no);

        printf("Double value is %lf \n", dbl);

        printf("Octal value is %o \n", no);

        printf("Hexadecimal value is %x \n", no);

        return 0;

     }

 

·    %d got replaced by value of an integer variable  (no),

·       %c got replaced by value of a character variable  (ch),

·       %f got replaced by value of a float variable  (flt),

·       %lf got replaced by value of a double variable  (dbl),

·       %s got replaced by value of a string variable  (str),

·       %o got replaced by a octal value corresponding to integer variable  (no),

·       %x got replaced by a hexadecimal value corresponding to integer variable

·       \n got replaced by a newline.

 

2.     In wwd_debug.h, wwd_debug.c , wiced_defaults.h

We defined Macros to control the log output for different MODULE.

Modules are Application, library, Webserver , Network, RTOS,

Security , WPS, Supplicant, Wiced , WWD(Wiced wi-fi Driver) .

 

We have good instructions and warnings for the log setting:

* ** WARNING for PRINTING **

*  If printing is enabled, the stack of each thread that uses printing

* must be increased to at least 4 kBytes since the printf function uses

a lot of memory (including dynamic memory)

/* Select which group of functions are allowed to print */

/* WPRINT_ENABLE_<MODULE>_ERROR - Enable print messages in the respective <MODULE> that are present

* as WPRINT_<MODULE>_ERROR.

* For instance, if WPRINT_ENABLE_WWD_ERROR is enabled, then trace messages that are under

* WPRINT_WWD_ERROR will be printed. This directive shall also result in an ASSERT if the target is built in DEBUG                                 mode.

* WPRINT_ENABLE_<MODULE>_DEBUG - Enable print messages in the respective module that are present as

* WPRINT_<MODULE>_DEBUG.

* For instance, if WPRINT_ENABLE_WWD_DEBUG is enabled, then trace messages that are under

* WPRINT_WWD_DEBUG will be printed.

 

* WPRINT_ENABLE_<MODULE>_INFO - Enable print messages in the respective module that are present as

* WPRINT_<MODULE>_INFO.

* For instance, if WPRINT_ENABLE_WWD_INFO is enabled, then trace messages that are under

* WPRINT_WWD_INFO will be printed.

 

If you disable all the logs, there will have a compiled error, so please keep this one at least:

#define WPRINT_ENABLE_APP_INFO           /* Application prints */

 

 

So general debug sequence for log enable:

    • Enable WPRINT_ENABLE_MODULE_INFO to track the process.
    • If found an error was printed out, check which module , then enable DEBUG and ERROR mode also. Be noted, Debug compile will go to an assert if enable ERROR layer .
    • Find the bug position , add more debug info by using the same level log print.

I think if you want to manage the log clearly , you can define one MACRO to just add your debug info ,like           #define WPRINT_ENABLE_BUG_DEBUG_INFO , after issue is fixed you can disable it .Another log print mode :

 

3.     Wiced_log_setting, it is often used on application area.

If you want to close the log , please change the log to WICED_LOG_OFF, the logs added in      the application will be disabled. And strongly suggest to use this debug info in application debug stage.

Log initialize at application_start and enum structure.

         wiced_log_init(WICED_LOG_INFO, render_log_output, wiced_time_get_time);

         wiced_log_msg(WLF_DEF, WICED_LOG_NOTICE, "wiced logging system is initialized\n");

 

typedef enum

{

    WICED_LOG_OFF = 0,

    WICED_LOG_ERR,

    WICED_LOG_WARNING,

    WICED_LOG_NOTICE,

    WICED_LOG_INFO,

    WICED_LOG_DEBUG0,

    WICED_LOG_DEBUG1,

    WICED_LOG_DEBUG2,

    WICED_LOG_DEBUG3,

    WICED_LOG_DEBUG4,

 

    WICED_LOG_PRINTF, /* Identifies log messages generated by wiced_log_printf calls */

 

    WICED_LOG_MAX

} WICED_LOG_LEVEL_T;

 

b: How to write to STDOUT .

use this function:

Enable time output with log together.

Filter Blog

By date:
By tag: