WHEN start to design Power Source with APDO, tester shall be taken consideration.
1) Use Third Lab verified tester
2) Use function power negotation tester
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.
1. CCG3PA VDDD is input and output power pin and specifications as below.
VDDD power supply input voltage specifications as below. ( If you are designing a DRP, recommend to select 3.0 -5.5V range.)
VDDD power output voltage specification is 3.3V. (When powered through VBUS_IN_DISCHARGE, the internal regulator generates VDDD of 3.3 V for chip operation. When powered through the VBUS_IN_DISCHARGE pin, VDDD cannot be used to power external devices and should be connected to a 1-µF capacitor for the regulator stability only. )
2. CCG3PA example code in CCGx power SDK have disabled internal regulator by default as per the schematic design based on CY4532 and existing referred customize EVKs.
Before any bring up or debug firmware customize, check the API void pd_hal_disable_vreg(uint8_t port) in the based example project at first to clear default setting.
3. If the design is DRP and supporting dead battery case (CCG3PA have Rd_DB for dead battery case support.), the internal regulator shall be adjust as per the conditions of battery. So that, CCGx Power SDK have three condition to disable internal regulator for your reference. This is recommendation and example/experience, it is low risk to adjust it as per real case.
(1) if device is powered by external VDDD (i.e not in dead battery), disable internal VBUS regulator.
if (dpm_stat->dead_bat == false)
{
pd_hal_disable_vreg (port);
}
(2) If the device is on disconnect and type-C error recovery.
if ((evt == APP_EVT_DISCONNECT) || (evt == APP_EVT_TYPE_C_ERROR_RECOVERY))
{
pd_hal_disable_vreg(port);
}
(3) Battery is weak but TYPE-C port is providing power to system. Check if Battery voltage is more than the voltage level of back to power supply the board from battery. if yes, disable internal regulator.
if (vbatt >= pd_get_ptr_bat_chg_tbl(TYPEC_PORT_0_IDX)->vbatt_dischg_en_volt)
{
pd_hal_disable_vreg (TYPEC_PORT_0_IDX);
}
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.
Customer use PSOC 4 CY8C4147AZI-S455 to design Remote controller, implement Segment LCD+ Capsense+ System control function, use Flash Em_EEPROM (version: V2.2) component to store system parameter, and the remote controller was used in hotel room, and when room ID card insert in power supply booth ,the AC power on ,and indoor aircon & remote controller start work, when remove the ID card ,the ac power down, indoor aircon & remote controller stop work
They feedback the remote controller can’t start up and no display after several working months.
We read the bad remote controller, and found the code section are the same, and EEPROM data are different from each other
We re-program the bad remote controller, and it can run well again
We checked KBA227502 & KBA227530 &KBA228069and modified cy_em_eeprom.c the following code
Cy_Em_EEPROM_Read() |
|
if((CY_EM_EEPROM_SUCCESS == ret) && (0u != seqNum)) { numRowReads = (context->numberOfRows <= seqNum) ? (context->numberOfRows) : (seqNum); numRowReads--; for(i = (seqNum - numRowReads); i <= seqNum; i++) { startRowAddr = GetRowAddrBySeqNum(i, context); if (0u != startRowAddr) { ...
|
if((CY_EM_EEPROM_SUCCESS == ret) && (0u != seqNum)) { numRowReads = (context->numberOfRows <= seqNum) ? (context->numberOfRows) : (seqNum); for(i = 0; i < numRowReads; i++) { startRowAddr = GetRowAddrBySeqNum(seqNum - ((numRowReads - 1) - i), context); if (0u != startRowAddr) { ...
|
|
|
CheckCrcAndCopy() |
|
if(CY_EM_EEPROM_SUCCESS == ret) { (void)memcpy((void *)(dstAddr), (void *)(writeRamBuffer + rowOffset), numBytes); }
|
if(CY_EM_EEPROM_SUCCESS == ret) { (void)memcpy((void *)(dstAddr), (void *)((uint32_t)writeRamBuffer + rowOffset), numBytes); }
|
|
|
Cy_Em_EEPROM_Write() |
|
/* Write the data to the specified flash row */ ret = WriteRow(emEepromRowAddr, writeRamBuffer, context); tmpRowAddr = emEepromRowAddr;
|
/* Calculate the checksum of a data header if redundant copy is disabled */ if(0u == context->redundantCopy) { writeRamBuffer[CY_EM_EEPROM_HEADER_CHECKSUM_OFFSET_U32] = (uint32_t) CalcChecksum((uint8_t *) &writeRamBuffer[0], CY_EM_EEPROM_HEADER_CHECKSUM_OFFSET); } /* Write the data to the specified flash row */ ret = WriteRow(emEepromRowAddr, writeRamBuffer, context); tmpRowAddr = emEepromRowAddr;
|
|
Cy_Em_EEPROM_Erase() |
|
if(0u != context->redundantCopy) { writeRamBuffer[CY_EM_EEPROM_HEADER_CHECKSUM_OFFSET_U32] = (uint32_t) CalcChecksum((uint8_t *) &writeRamBuffer[CY_EM_EEPROM_EEPROM_DATA_OFFSET_U32], CY_EM_EEPROM_EEPROM_DATA_LEN); }
|
if(0u != context->redundantCopy) { writeRamBuffer[CY_EM_EEPROM_HEADER_CHECKSUM_OFFSET_U32] = (uint32_t) CalcChecksum((uint8_t *) &writeRamBuffer[CY_EM_EEPROM_EEPROM_DATA_OFFSET_U32], CY_EM_EEPROM_EEPROM_DATA_LEN); } else { /* Calculate the checksum of a data header if redundant copy is disabled */ writeRamBuffer[CY_EM_EEPROM_HEADER_CHECKSUM_OFFSET_U32] = (uint32_t) CalcChecksum((uint8_t *) &writeRamBuffer[0], CY_EM_EEPROM_HEADER_CHECKSUM_OFFSET); }
|
|
|
FindLastWrittenRow() |
|
/* Some record in EEPROM was found. Store found sequence * number and row address. */ prevSeqNum = seqNum; *lastWrRowPtr = emEepromAddr;
|
if((*(uint32_t *)(emEepromAddr + CY_EM_EEPROM_HEADER_CHECKSUM_OFFSET)) ==((uint32_t) CalcChecksum((uint8_t *)emEepromAddr, CY_EM_EEPROM_HEADER_CHECKSUM_OFFSET))) { /* Some record in EEPROM was found. Store found sequence number and row address. */
prevSeqNum = seqNum; *lastWrRowPtr = emEepromAddr; }
|
|
But we still found Cy_Em_EEPROM_Write() following issue
for(; i <= seqNum; i++)
{
……
}
When seqNum=0xFFFFFFFF ,the for loop will loop forever ,and no chance jump out
So we need to add some special deal before it
if(seqNum >= (0xFFFFFFF0))
{
seqNum=1;
}
Cy_Em_EEPROM_Write() |
|
for(wrCnt = 0u; wrCnt < numWrites; wrCnt++) { uint32 skipOperation = 0u; /* Get the sequence number of the last written row */ uint32 seqNum = CY_EM_EEPROM_GET_SEQ_NUM(emEepromRowAddr);
/* Get the address of the row to be written. The "emEepromRowAddr" may be * updated with the proper address (if wear leveling is used). The * "emEepromRowRdAddr" will point to the row address from which the historic * data will be read into the RAM buffer. */ GetNextRowToWrite(seqNum, &emEepromRowAddr, &emEepromRowRdAddr, context); |
for(wrCnt = 0u; wrCnt < numWrites; wrCnt++) { uint32 skipOperation = 0u; /* Get the sequence number of the last written row */ uint32 seqNum = CY_EM_EEPROM_GET_SEQ_NUM(emEepromRowAddr);
if(seqNum >= (0xFFFFFFF0)) { seqNum=1; }
/* Get the address of the row to be written. The "emEepromRowAddr" may be * updated with the proper address (if wear leveling is used). The * "emEepromRowRdAddr" will point to the row address from which the historic * data will be read into the RAM buffer. */ GetNextRowToWrite(seqNum, &emEepromRowAddr, &emEepromRowRdAddr, context); |
|
We have modified cy_em_eeprom.c ,and download the attached file
Please update it as the following path:
C:\Program Files (x86)\Cypress\PSoC Creator\4.X\PSoC Creator\psoc\content\CyComponentLibrary\CyComponentLibrary.cylib\Em_EEPROM_Dynamic_v2_X\API
In CapSense_v7_0, why the 'IDAC Gain' parameter of widget shows in Tuner is different with Customizer setting.
In CapSense_v7_0 customizer, when 1200nA/bit, 2400nA/bit or 4800nA/bit option is selected as the widget 'IDAC Gain', in Tuner it will be mis-displayed as 2400nA/bit, 4800nA/bit and N/A respectively. This is a known defect of CapSense Tuner tool, which cause the 'IDAC Gain' parameter miss synchronization between Customizer and Tuner.
The problem exists only with the CapSense Tuner tool. But the IDAC gain selection is correctly handled by the CapSense Customizer tool. User is still able to setup any gain by using the CapSense Customizer tool.
DAC Gain synchronization relationship between Customizer and Tuner
Widget |
Customizer |
Tuner |
Btn 0 |
37.5 |
37.5 |
Btn 1 |
75 |
75 |
Btn 2 |
300 |
300 |
Btn 3 |
600 |
600 |
Btn 4 |
1200 |
2400 |
Btn 5 |
2400 |
4800 |
Btn 6 |
4800 |
N/A |
This is an example program based on libusb that automatically takes the first frame and streams data from the endpoint then calculates the FPS.
Please notice that only bulk transfer is supported in the current version. This application does not contain a decoder so RAW format is also supported.
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.
Package Version
ahd-2021_0629
Release Date
2021-06-29
Description
Cypress Android release for the broad market.
This release has been qualified on Hikey 960 and NXP i.MX8MQuad Evaluation Kit (EVK) platform.
Customers wishing to leverage the Android Open Source Platform now have an out of the box Android solution for Cypress's connectivity parts.
The release package includes:
* ahd
* device
*hikey960
*imx8mq
* firmware
* nvram
* AndroidBringup_with_AHD.pdf
Test Environment:
* Hikey 960
* NXP i.MX8MQuad Evaluation Kit
* 4373/43012/54591 Sanity and VTS
Change Log
[2021-06-29]
* Update AHD drivers
* Upgrade supporting Hieky960 to Android 11 and NXP Android NXP to 10.0.0_2.0.0
This release is an update to Bluetooth SDK 2.9.
AIROC™ Bluetooth® SDK 3.0 is targeted for the CYW20706, CYW20719B2, CYW20721B2, CYW20735B1,
CYW20835B1, CYW20819, CYW20820, CYW89820, and CYW43012 AIROC™ Wi-Fi & Bluetooth® combo chips (for
embedded Bluetooth® development only).
ModusToolbox™ with the 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.0.
This blog gives detailed steps on how to use chipload.exe to program Cypress Bluetooth chips CYW207xx.
Chipload (/<BTdevice_workspace>/wiced_tools/ChipLoad) is a tool provided by Cypress to program the device without using WICED SDK or ClientControl utility. To program to device using Chipload, first run the ChipLoad.exe from the folder location: C:\Users\shjl\Documents\WICED-Studio-6.2\wiced_tools\ChipLoad\Win32
A specific command format is used to download the Hex file to the device, as follows:
./ChipLoad.exe -BLUETOOLMODE [-PORT COM port] [-BAUDRATE nnnn] [-NOVERIFY] [-CHECKCRC] [-MINIDRIVER minidriver file] [-CONFIG config data file] [-BTP btp file name] [-NODLMINIDRIVER] [-LOGTO[X} optional log file] [-DLMINIDRIVERCHUNKSIZE byte size]
Detailed information about every parameter is given below:
PORT : UART COM port id (HCI UART)
BAUDRATE : to specify the Baudrate of the device, typically 115200
NOVERIFY : an optional parameter that prevents the verification of the bytes regardless of what is specified in BTP file
CHECKCRC : an optional parameter that directs the ChipLoader to do CRC checks on loaded areas
MINIDRIVER : to specify the minidriver hex file which is used to load the program Hex file to the device
BTP : to load the BTP file which contains configuration data
CONFIG : to specify the program .hex file
NODLMINIDRIVER : used if device has never been programmed or device is in recovery mode
LOGTO (or LOGTOX) : an optional parameter allowing to print the logs in a text file, LOGTOX prints more detailed information
Example:
ChipLoad.exe -BLUETOOLMODE -PORT COM23 -NOVERIFY -MINIDRIVER C:\Users\shjl\Documents\WICED-Studio-6.2\20719-B1_Bluetooth\platforms\minidriver-20739A0-uart.hex -BTP C:\Users\shjl\Documents\WICED-Studio-6.2\20719-B1_Bluetooth\platforms\20719_OCF.btp -CONFIG C:\Users\shjl\Documents\WICED-Studio-6.2\20719-B1_Bluetooth\build\gpio-CYW920719Q40EVB_01-rom-ram-Wiced-release\gpio-CYW920719Q40EVB_01-rom-ram-Wiced-release.hex
Executing above command downloads snip.gpio app to the CYW920719Q40EVB-01 EVAL board.
Note: You can include all the needed files into a single folder, so that it becomes more simpler to access the files and program the device.
Show LessIn this training session/Blog we aim to cover the basic regulatory aspects involved in getting a Wi-Fi product certified and Infineon’s equivalent of this regulatory process that is the process that we expect customers to follow while submitting a request for a per product CLM BLOB.
Disclaimer: This training was attempted to get customers started with the regulatory aspects of a Wi-Fi device. For a detailed understanding of everything that needs to be done, please refer to the CLM Regulatory Manual.
The discussion flow in the presentation is written below.
Attached is the presentation that was used for the discussion as well as the video recording of the same.
The Video recording has been split up into multiple parts and added into archives as there was a limitation on the file size that could be uploaded at the time of publishing this Blog.
This project was submitted by @Vinayyn in The Infineon Great PSoC 6 Design Challenge with Mouser and Electromaker.io and was one of the winners!
Project Technology Focuses
Project Requirements
Project Description
This end-end proof of concept (PoC) Smart Home project aims to bring to life multiple common, automated functions you’d see in that type of environment. The PSoC 6 WiFi-BT Pioneer Kit was used along with multiple sensors to implement: CapSense capacitive-sensing for touch UI in appliances, intruder detection and alert using motion sensor, noise detection via PDM Mic, light control via ambient light sensing, and more. This sensor data was aggregated and alerts are displayed on the kit’s TFT display via emWin software libraries and transmitted to an AWS dashboard via on-board Wi-Fi.
Project Links
Resource List
Hardware:
Software:
This project was submitted by @Knaveen in The Infineon Great PSoC 6 Design Challenge with Mouser and Electromaker.io and was one of the winners!
Project Technology Focuses
Project Requirements
Project Description
This innovative project implements voice recognition at the edge for an IoT Node using the PSoC 63 MCU with Bluetooth LE connectivity implemented. The developer creating this project generated and trained a voice recognition model to take action off of specific keywords commonly used in home automation type applications – and then deployed it on the PSoC 6 MCU using ModusToolbox. PSoC 6 would send Bluetooth LE transmissions to a peripheral upon recognition of certain commands – for example “Turn On/Off AC!”.
Project Links
Resource List
Hardware:
Software:
This project was submitted by @Bastiaan Lee in The Infineon Great PSoC 6 Design Challenge with Mouser and Electromaker.io and was one of the winners!
Project Technology Focuses
Project Requirements
Project Description
This project consists of implementation a very robust audio processing program on PSoC 6 – taking advantage of its peripherals as well as enablement in ModusToolbox to make an IoT Audio Sensor node application. The program records audio samples with the PDM microphone on the PSoC 6 WiFi-BT Prototyping Kit, converts that to PCM data which then going through a Fast Fourier Transform with HANN windowing, to be able to split the audio data into octaves. Based on A/C/Z weighting, the audio data is then further calculated into data that represents what our ears do actually hear. This audio data is transmitted via Wi-Fi and graphed on a series of easy-to-use dashboard as well.
Project Links
Resource List
Hardware:
Software:
Community Tip: Update Your Avatar
Click on ‘Upload an Avatar’ to add a picture or choose a generic system image via ‘Choose a Collection’
Select location of image to be uploaded and edit as instructed
Show Less
This blog post documents the method to read out the firmware version from a CCG3PA chip.
The firmware version information can be retrieved in the form of VDMs. This handling is taken care in the uvdm.c file in the Power SDK:
Since CCG3PA supports only single firmware image, the bootloader version and the firmware version of image 1 are read from the metadata by the system functions. The firmware and the bootloader version are given out in hex format.
The above implementation is with respect to the op-code present in the VDM sent by a Cypress board. In case if custom standard testers are employed in production environment for reading out the firmware version that is programmed into the PD controller, the customers can form their custom VDM command in the tester and can customize the SDK accordingly to form the custom UVDM response.
Below is a sample code snippet in which CCG3PA gives out the firmware version information if it is connected to a BCR device. CCG3PA first sends Discover Identity VDM command after the completion of PD negotiation between source and sink. If the VID and PID of sink matches with the VID and PID of EZ PD BCR device (i.e. VID= 0X4B4 and PID=0x3177), CCG3PA will respond by sending a UVDM command which contains the firmware version.
As per USB-PD spec,
The unstructured vendor defined message is sent with the vendor ID set to appropriate value (0x4B4), VDM type set to 0 (unstructured vdm) and rest fields were set to 0 (which can be customized as per requirement).
The UVDM is sent after detection of EZ PD BCR through a timer callback. The function cc_device_version() is used to send the UVDM.
App event APP_EVT_PD_CONTRACT_NEGOTIATION_COMPLETE is triggered in app_event_handler() function once the PD negotiation is complete. Discover Identity message is sent after negotiation complete event through a timer callback.
The above image presents the code being used to extract the firmware version information from the metadata using the system functions once EZ PD BCR device is detected.
Following is the detail of the UVDM from CC logs captured using CY4500 EZ PD Protocol Analyzer.
DATA OBJECT 4 and DATA OBJECT 5 contain the firmware version.
For information on CCGx firmware version structure, refer to Table-13 in the CCGx Power SDK User Guide: (https://www.cypress.com/documentation/software-and-drivers/ez-pd-ccgx-power-software-development-kit).
Attached to this post is the project which recognizes Ez-PD BCR as a sink and sends UVDM containing the firmware version information. All changes to project are made in app.c file.
ModusToolbox® with the 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.