AIROC™ Bluetooth® SDK 3.3 is targeted for the CYW20706, CYW20719B2, CYW20721B2, CYW20735B1, CYW20736, CYW30739, CYW20835, CYW20819, CYW20820, CYW89820, CYW43012 AIROC™ Wi-Fi & Bluetooth® combo chips (for embedded Bluetooth® development only), and CYW5557x AIROC ™ Wi-Fi & Bluetooth® combo chips (for embedded Bluetooth® development only).

ModusToolbox™ with the AIROC™ Bluetooth® SDK software library provides a complete development environment to allow you to quickly create Bluetooth®-enabled IoT solutions for beacons, trackers, smart watches, audio devices, HID devices (remotes, mice, and keyboards), medical devices, mesh, or home automation platforms. This document describes the features and known limitations for Bluetooth® SDK 3.3.

AIROC™ Bluetooth® SDK 3.2 is targeted for the CYW20706, CYW20719B2, CYW20721B2, CYW20735B1, CYW20736, CYW30739, CYW20835, CYW20819, CYW20820, CYW89820, CYW43012 AIROC™ Wi-Fi & Bluetooth® combo chips (for embedded Bluetooth® development only), and CYW5557x AIROC ™ Wi-Fi & Bluetooth® combo chips.

ModusToolbox™ with the AIROC™ Bluetooth® SDK software library provides a complete development environment to allow you to quickly create Bluetooth®-enabled IoT solutions for beacons, trackers, smart watches, audio devices, HID devices (remotes, mice, and keyboards), medical devices, mesh, or home automation platforms. This document describes the features and known limitations for Bluetooth® SDK 3.2.

ModusToolbox® with the AIROC™ Bluetooth SDK provides a complete development environment that allows you to quickly create an IoT solution utilizing world-class Bluetooth/Bluetooth Low Energy connectivity technologies.  This document provides the details of various features, modes, and limitations associated with the supported hardware development platforms.

If online resources are not handily accessible to you, ModusToolbox offers an option to let you use offline content with it. Refer to this link for the original introduction and official offline content.

This guide shows you how to use offline content in Eclipse IDE for ModusToolbox, typically on Windows, as a supplement to the above link. 

Steps:

1. Download an official/unofficial offline content package. You might refer to Reference #2 for the unofficial offline content package.
2. Unzip the package to the default path, i.e., %USERPROFILE%\.modustoolbox\. You'll find a folder offline is created under that path after the extraction. Now %USERPROFILE%\.modustoolbox\offline is your offline content location, e.g., C:\Users\xxx\.modustoolbox\offline.
3. Add the variable CY_GETLIBS_OFFLINE to the environment variables and set the value to true, as below, which enables ModusToolbox to use the offline content prior to the online content:
   
4. (OPTIONAL) Delete the variable CyRemoteManifestOverride or CY_GETLIBS_CACHE_PATH if you find it in the environment variables, to avoid incoherence.
5. (OPTIONAL) If you unzip the offline content package to somewhere else than the default path in step #2, then you need to add the variable CY_GETLIBS_OFFLINE_PATH to the environment variables and set the value to your offline content location. Use slashes to replace all the backslashes in the string, e.g., C:/Users/xxx/.modustoolbox/offline.
6. Now open Eclipse IDE for ModusToolbox. You can use it as before, and find the offline content is enabled by default. See below:
   

Reference:

1. ModusToolbox User Guide
2. Self-released ModusToolbox Offline Content Package
3. ModusToolbox Offline Content Generator

Introduction

The SFLASH of CYW20706 is divided into the following section based on different purpose and function. There are three types of section:

SS (Static Section), static section used internally by chip firmware. It contains configuration records that don’t change after factory programming.

VS (Volatile Section), volatile section used by the application and the stack to store data. It may be modified frequently.

DS (Data Section), data section used to store application’s executable binary image built from source codes.

Section Layout Configuration (WICED SDK 6.2.1 for Example)

1. Flash Layout for non-OTA application

The default section layout configuration for non-OTA application is in BTP file. Its path is WICED-Studio-6.2.1.2\20706-A2_Bluetooth\platforms\CYW920706WCDEVAL\CYW920706WCDEVAL_SFLASH.btp.

The information can also be seen in the generated HEX file. The HEX file follows the intel HEX format:  https://developer.arm.com/documentation/ka003292/1-0

:02000004FF00FB

:280000000108006999994204204EB1FD0400FFFFFFFF4006007766556A7020020A000030000000100000001004

:F93000000AFB0000020D009DF8380021463A4600F07CFA044696F88000AAF7CFBA000000F022FC034C044E08B18BF749B98BF73FB90000F850210080D620000248006800F6FD608BF

…

As shown above, the address offset is 0xFF00. There are two parts in the application image: SS section and DS section. The SS section starts from 0x0000. The DS section starts from 0x3000. They are same with the configuration in the BTP file.

2. Flash Layout for OTA Application

If the application supports OTA Firmware Upgrade. It will need one more SS section to back up the original configuration, VS section to store customer data and DS section to store the download OTA image.

The flash layout configuration can be found in the file C:\Users\zhxh\Documents\WICED-Studio-6.2.1.2\20706-A2_Bluetooth\libraries\fw_upgrade_lib\fw_upgrade.c as follows:

We can get the following section layout from the configuration:

C2HCD Tool is released to help you convert WICED Bluetooth firmware/RAM_patch format from c to hcd.

WICED Studio provides an official script tool to help developers convert WICED Bluetooth firmware/RAM_patch format from hcd to c. The script tool is named hcd2c.pl and is located at <wiced_sdk>\43xxx_Wi-Fi\libraries\drivers\bluetooth\firmware\tools.

However, in some conditions, developers might want to revert the firmware format from c to hcd. C2HCD Tool can help in this case.

Refer to this page for usage and source.

Note: C2HCD Tool is not an Infineon product. Use this tool at your own risk. Report issues to the author only.

This is the sample code for using DMA to acquire ADC samples.

This is a simple main.c file, which needs to be complied based on SDL 7.2.0.

Tested on CYTVII-B-E-1M-176-CPU evaluation board, where MCU is CYT2B7, rev D.

Nov.12th, 2021

Finn Yang

Scope and purpose

This document describes the Infineon Wi-Fi onboarding service that allows your device to transfer Wi-Fi credentials over a Bluetooth® LE link. It only describes the custom Bluetooth® LE GATT service and its behavior. The actual implementation is up to the user.

This document is primarily intended for anyone who want to use Infineon Wi-Fi onboarding service to onboard Wi-Fi using Bluetooth® LE.

The project attached below shows how to update the Connection Parameters in a BLE connection using the PSoC 6 BLE device. Peripheral device can update the connection parameters by sending a Connection Parameter Update Request packet to the Central device. In this project, once the device connects to a peer device, a Connection Parameter Update Request can be sent from the GAP Peripheral when the user presses the switch (SW2) on the kit.

Schematic Diagram:

Hardware Required: CY8CKIT-062-BLE PSoC 6 BLE Pioneer Kit

Software Required: PSoC Creator™ 4.4, CySmart 1.3, Serial Terminal application (like TeraTerm)

PSOC Creator project and project datasheet are attached below.

There are two ways to debug the makefiles of the ModusToolbox Project. One is generically supported by GNU Make and the other is provided by ModusToolbox.

1>>>

This is supported by GNU Make.

Append --debug[=options] to the make command, e.g.:

make program --debug=verbose

This parameter enables the GNU Make to print more information in addition to normal processing. The information shows which makefiles and sources were processed and how they were processed.

Alternative options are all, basic, verbose, implicit, jobs, makefile, none.

See: https://www.gnu.org/software/make/manual/html_node/Options-Summary.html

2>>>

This is provided by ModusToolbox.

Append VERBOSE=true to the make command, e.g.:

make program VERBOSE=true

This parameter enables the debug flag so the makefiles can print more messages for debugging. The messages reveal the insights of the ModusToolbox building system.

This is equivalent to setting variable VERBOSE to "true" or "1" in the makefile of your ModusToolbox project. See below:

See section 4.9.1 of ModusToolbox User Guide.

CCGx POWER SDK DEFALUT FLASH LAYOUT:

The First ROW of application shall be correct and the value of those value define/pre-calculate shall be matched. 

 (For example, Original CYPD3171 example code using below default values)

1) Manual application placement address.

2) CY_APPL_ORIGIN in  cm0gcc.ld.

3) CCG_BOOT_LOADER_LAST_ROW in  flash_config.h

<HOW TO CALCULATE ABOVE THREE VALUES?>

Step 1: Confirm the Application image placement address from the HEX file of bootloader.  (From the bootloader HEX file, you can select the row of below after the bootloader. ) For example, 0x00001300.

Step 2: Use 0x1300 as application first row, and then, you can get CY_APPL_ORIGIN = change HEX format to DEC format of 0x1300 = 4864.

Step 3: CCG_BOOT_LOADER_LAST_ROW +1 = (Application image placement address)/0x80. CCG_BOOT_LOADER_LAST_ROW = 0x25.

If the CCG3PA CYPD3171 design is DRP and with battery supply, the CYPD3171-24LQXQ_pb_add_pb is correct example code beginning to customize firmware.  There is an default battery state machine example in file power_bank.c. 

The APIs in the file power_bank.c is below.

(1) void pb_typec_set_current (uint16_t cur_10mA)

>>This function is for setting current limit in sink mode using PWM by default. The PWM is based on CY4532 hardware design. Based on hardware design, it is possible to set as GPIO drive, I2C transition, .... 

The parameter  uint16_t cur_10mA comes current of PD negotation. 

(2) static void pb_typec_configure_sink(uint8_t port)

>>This function is for configuring Type-C power role from Source to Sink by force. 

(3)void pb_event_handler(uint8_t port, uint32_t evt)

>> This function handles events from dpm. There are two cases handling:

See if we are waiting for disconnect as source when battery is weak. If yes, configure TYPE-C port as sink.

If CCG3PA locked as as sink on TYPE-C port then initiate a PR SWAP if battery is  in normal mode and port partner is DRP and not externally powered.

(4)static void pb_vbus_dis_cb (uint8_t port)

>> This function is callback function of power bank VBUS disable process, but the function is NULL by default.  This function could add some operations after VBUS discharge or adding ADC here for VBUS Safe voltage monitoring. 

(5) void pb_task_init(void)

>> This function is PowerBank task initialization routine. At initialization, Battery can be in following states:

1) Battery is normal and powering the system.

2) Battery is dead and TYPE-C VBUS is powering the system.

(6)static void pb_pr_swap_cb(uint8_t port, resp_status_t resp, const pd_packet_t* pkt_ptr)

>> This function is call back for PR_SWAP. If PR SWAP successfully transmitted, clear the flag.

(7) static void pb_debounce_cb(uint8_t port, timer_id_t id)

>> This function is adding additional debounce time  if the battery state need be changed by hit the threshold of each battery states.

(8) void pb_bat_monitor(void)

>> This function is handle power bank state based on battery status, the battery status was defined by measured battery voltage and currently battery states. 

The Battery state machine running in pb_bat_monitor(), below parameters need be input. 

1) Battery real voltage.  Relates API: static uint16_t pb_get_battery_voltage(void)

2) Battery charging parameters. Relates structure define:

typedef struct
{
uint8_t table_len; /**< Battery charger parameter table length in bytes*/
uint8_t reserved_0; /**< Reserved for future use*/
uint16_t vbatt_max_volt; /**< Maximum battery voltage in mV. */
uint16_t vbatt_cutoff_volt; /**< Minimum battery voltage below which device should stop discharging. */
uint16_t vbatt_dischg_en_volt; /**< Battery voltage at which discharge can be re-enabled. */
uint16_t vbatt_max_cur; /**< Maximum charging current allowed for the battery in mA. */
uint16_t reserved_1; /**< Reserved for future use*/
} bat_chg_params_t;

There are four possible battery states as below.

typedef enum
{
PB_BATTERY_STATE_NORMAL = 0, /* Battery in normal/charged state. */
PB_BATTERY_STATE_DB_TYPEC_CHARGING = 1, /* Battery is weak and getting charged over TYPE-C. */
PB_BATTERY_STATE_DB_NOT_CHARGING = 2, /* Battery is weak and nothing connected. */
PB_BATTERY_STATE_DB_TYPEC_WAIT_DC = 3, /* Battery is weak, TYPE-C port is source and waiting for disconnect. */
PB_BATTERY_SATTE_MAX = 4,
} pb_battery_state_t;

The Simple State machine flow chat.

WHEN start to design Power Source with APDO, tester shall be taken consideration. 

1) Use Third Lab verified tester

• QuadraMAX https://usb.org/estore

2) Use function power negotation tester

• USBCEE www.usbcee.com 
• Power-Z https://www.chargerlab.com/category/power-z/ 
• .... (Others)

3) Make a Tester by CCG3PA CYPD3171 (CY4532)

The mainly steps for make a Tester of USB PD SOURCE and specified to APDO request. (Based on the hardware of CY4532, if the target board is CCG3PA customized board, the project pin assignment shall be clean at first.)

Step 1. New branch/created a project from CCGx Power SDK and select CYPD3171-24LQXQ_pb as example code. And rename to the name you like to, for example, CYPD3171-24LQXQ_pps. You will get a project like below:

Step 2. Open config.h file and find out #define APP_PPS_SINK_SUPPORT (0u) and changed to #define APP_PPS_SINK_SUPPORT (1u). 

Step 3. Went through all of APIs offered by CCGx Power SDK and decide to keep or comments out as per requirements. 

(1) Below APIs from CCGx Power SDK.

static void snk_recontract_timer_cb (uint8_t port, timer_id_t id);

static void snk_recontract_cb (uint8_t port, resp_status_t resp, const pd_packet_t *pkt_ptr);

static void snk_recontract_timer_cb (uint8_t port, timer_id_t id);

uint8_t hpi_user_reg_handler(uint16_t addr, uint8_t size, uint8_t *data)

void app_pps_sink_disable(uint8_t port);

(2) Based on the API uint8_t hpi_user_reg_handler(uint16_t addr, uint8_t size, uint8_t *data), it is difficult to transform the Voltage and Current clearly. So that, I refer this API and make additional API to initial APDO request directly. 

void pps_request_handler(uint8_t port, uint32_t voltage, uint32_t current)
{
int8_t i;
const dpm_status_t *dpm_stat;

dpm_stat = dpm_get_info (TYPEC_PORT_0_IDX);

for(i = receive_src_pdo_count; i >= 0; i--)
{
if(receive_src_pdo[i].fixed_src.supply_type == PDO_AUGMENTED)
{
if((receive_src_pdo[i].pps_src.max_volt * 100 >= voltage) &&
(receive_src_pdo[i].pps_src.min_volt * 100 <= voltage))
{
pps_request.val = 0;
pps_request.rdo_pps.obj_pos = i+1;
pps_request.rdo_pps.out_volt = voltage/20;

if(receive_src_pdo[i].pps_src.max_cur * 50 >= current)
{
pps_request.rdo_pps.op_cur = current/50;
pps_request.rdo_pps.cap_mismatch = false;
}
else
{
pps_request.rdo_pps.op_cur = receive_src_pdo[i].pps_src.max_cur;
pps_request.rdo_pps.cap_mismatch = true;
}
pd_pps_flag = true;

break;
}
}
}
/* Operation is only valid if we are a sink and PD contract exists. */
if ((dpm_stat->contract_exist != 0) && (dpm_stat->cur_port_role == PRT_ROLE_SINK) &&
(dpm_stat->spec_rev_sop_live >= PD_REV3))
{
app_prog_rdo[port] = pps_request;
app_pps_snk_en[port] = true;
first_request =1; 
/* Start a timer which will start re-negotiation so that PPS source can be selected. */
timer_start (port, 0x91, 1, snk_recontract_timer_cb);
}

}

Step 4. Re-build the firmware and re-fresh the binaries of CYPD3171.

Source Code: https://github.com/zhao1mh/webcamtest

This is a simple example webcam test program using SDL2. It only supports YUY2 format. The UVC device should have VID:0x04b4&PID:0x00f9. Frames per second are calculated with a timer. 

It shows that USB transfer will not use too many system resources. Actually, the real reason for the low FPS is the efficiency of the Video Player.

Tested Platform: RaspberryPi 400 & Ubuntu

Author: Eddie Zhao

Version : 1.02

Date: 8/12/2021Cancel changes

Build:

sudo apt-get install libusb-1.0-0-dev libsdl2-dev

git clone http://github.com/zhao1mh/webcamtest.git
cd webcamtest
./configure
make

Question: To achieve better software version control, can the hex filename generated by PSoC Creator add timestamp automatically?

Answer: Yes. PSoC Creator provides a post-build option in linker config GUI to enable customers to execute customize single linker script command or a bat file that includes multi commands.

For example: add the below linker script command in the post-build text box can make PSoC Creator generate a bin file besides the hex file.

"C:\Program Files (x86)\Cypress\PSoC Creator\4.4\PSoC Creator\import\gnu\arm\5.4.1\bin\arm-none-eabi-objcopy" -S -O binary ".\CortexM0p\ARM_GCC_541\Debug\Design01.elf" ".\CortexM0p\ARM_GCC_541\Debug\Design01.bin"

But add timestamp into hex file needs require multi commands, so a bat file should be used to realize this feature.

Step1: Create a text file named HexTimeStamp and save it as a bat file.

Step2: Add command "..\HexTimeStamp.bat" ${OutputDir} ${ProjectShortName} in post build text.  

Step3: Add below script  in bat file.

 :: Post-build command "..\HexTimeStamp.bat" ${OutputDir} ${ProjectShortName}， bat file must be placed in the same path (deep level) as project .cydsn folder
:: ${OutputDir} = %1，the path of hex file locate at
:: ${ProjectShortName} = %2, the name of project and hex file

:: Print date and time value, like Wed 08/25/2021_13:38:44.32
echo %date%_%time%
:: relocate path to where hex file locate at, like \CortexM4\ARM_GCC_541\Debug\
cd %1

::echo off
:: format month+day data, 08/25 --> 0825
set date_num1=%date:~4,5%
set date_num1=%date_num1:-=%
set date_num1=%date_num1:/=%
:: format year data, /2021 --> 2021
set date_num2=%date:~9,5%
set date_num2=%date_num2:-=%
set date_num2=%date_num2:/=%
:: format hours:minute:second data, 13:38:44 --> 133844
:: if first value is 0, add zero in the left side. 3:38:44 -->033844
set time_num=%time:~0,8%
set time_num=%time_num::=%
if "%time_num:~0,1%"==" " set "time_num=0%time_num:~1%"

echo on
echo "Insent time stamp in hex file's name >>"
:: combine into final time stamp value and add into hex file name
:: .\Hex_TimeStamp.hex .\Hex_TimeStamp_20210825_133844.hex
copy .\%2.hex .\%2_%date_num2%%date_num1%_%time_num%.hex

Step4: Build project multi times, you can find timestamp is added into hex file name.

PSoC Creator Build log for bat file：

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: ..\HexTimeStamp.bat Hex_TimeStamp 
:: ..\Hex_TimeStamp.cydsn>echo Wed 08/25/2021_13:38:44.32 
:: ..\Hex_TimeStamp.cydsn>cd .\CortexM4\ARM_GCC_541\Debug\ 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>set date_num1=08/25 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>set date_num1=08/25 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>set date_num1=0825 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>set date_num2=/2021 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>set date_num2=/2021 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>set date_num2=2021 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>set time_num=13:38:44 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>set time_num=133844 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>if "1" == " " set "time_num=033844" 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>echo on 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>echo "Insent time stamp in hex file's name >>" 
:: ..\Hex_TimeStamp.cydsn\CortexM4\ARM_GCC_541\Debug>copy .\Hex_TimeStamp.hex .\Hex_TimeStamp_20210825_133844.hex 
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

ModusToolbox® with the AIROC™ Bluetooth SDK provides a complete development environment that allows you to quickly create an IoT solution utilizing world-class Bluetooth/Bluetooth Low Energy connectivity technologies.  This document provides the details of various features, modes, and limitations associated with the supported hardware development platforms.

This release is an update to AIROC™ Bluetooth® SDK 3.0.  

AIROC™ Bluetooth® SDK 3.1 is targeted for the CYW20706, CYW20719B2, CYW20721B2, CYW20735B1, CYW20736, CYW20739, CYW20835, CYW20819, CYW20820, CYW89820, and CYW43012 AIROC™ Wi-Fi & Bluetooth® combo chips (for embedded Bluetooth® development only).

ModusToolbox™ with the AIROC™ Bluetooth® SDK software library provides a complete development environment to allow you to quickly create Bluetooth®-enabled IoT solutions for beacons, trackers, smart watches, audio devices, HID devices (remotes, mice, and keyboards), medical devices, mesh, or home automation platforms. This document describes the features and known limitations for Bluetooth® SDK 3.1.