Code Examples Forum Discussions

Hardware: The example is running on the TraveoII starter kit CYTVII-B-E-1M-SK, populated with CYT2B75CAD.

Software: SDL Version 7.1.0 or 7.8.0, not shure

PDMA, Datawire and DW are synonyms.

The PDMA is repeatedly executing a 2Dtransfer to move 8 x 128 bytes from memory to the input of the SCB’s TXFifo. The SCB’s TXFifo is triggering the PDMA when empty.

The UART output can be monitored with a terminal program like PuTTY configured as COMx, 115200 Bd, 8N1.

Please find code attached.

Hi,

let us share the pramaeter file for iMOTION2go with iMOTON Solution Designer (iSD) ver1.3.0 and FW ver5.3.7.

You can apply default parameter in iSD for iMOTION2go.

Then it is needed to modify many parameters as below.

GKpin/comp -> GKpin
GPIO7 no-check -> check, output

Retaed inverter output current 0.2Arm -> 0.5Arms
Maximum inverter DC-bus voltage 25V -> 20V
Bootstrap capacitor charge time per phase 3.33ms -> 10ms

Minimum single shunt phase shift active pulse 3us->2us

Motor rated amps/phase 0.4Arms -> 0.2Arms
Motor back EMF constant 38.000 -> 0.210

Motor nominal voltage 200Vrms -> 15Vrms
Motor type PM -> IPM
Stator resistanced/phase 38 -> 6.2
IPM motor stator Iq inductance/phase 195mH -> 0.58mH
IPM motor stator Id inductance/phase 192mH -> 0.52mH

Load type  Select Item -> Simple
Rated power 100W -> 2W
Minimum speed 100 RPM -> 6000 RPM
Maximum speed 2730 RPM -> 16383 RPM

Speed control update rate scaler 2 -> 1

Speed feedback filter time constant 10ms -> 0.2ms
Speed regulator proportional gain 1.0 -> 0.25
Speed regulator integral gain 4rad/s -> 1.38 rad/s

Open loop ramp rate  200rpm/s -> 800rpm/s
Regeneration current limit 0% -> 5%
Low speed limit 40% -> 90%
Low speed threshold 200rpm -> 6000rpm
Speed control input ramp rate imit 100rpm/s -> 800rpm/s

Flux estimator time constant 15ms -> 10ms

DC bus critical overvoltage fault level 23.8V -> 19V
Overvoltage fault enable no-check -> check
Undervoltage fault enable no-check -> check
Rotor lock fault enable no-check -> check
Phase loss fault enable check -> no-check
Current Offset Protection check -> no-check

The .zip file is used for iMOTION2Go and iSD ver1.3.0 and FW ver5.3.7. It can be used as is without modification.

Usage:

1. install iSD ver1.3.0 (skip if already done)
2. Download the zip file and extract it
3. Open iSD and File -> Open Project -> Select "i2024_03_04 iMOTION2Go_for_pack5.3.7_iSD1.3.0.cwproj" in "settings" folder.
4. Build and program
5. Start motor in dashboard, slide target speed to adjust RPM

Best Regards,
Hayashi.K

This Code Example demonstrates the function of the fast comparator. The threshold for fast comparator channel 0 is set to 2/VAREF, and when the input voltage exceeds this threshold, the FC interrupt occurs and P33.7 is toggled.

installations

TC397XP

development board

The TC397 Triboard was used for testing.

precondition

The BIFACES tool and Tasking compiler are required.

compiling

Import to Biface and modify the Tasking compiler installation path for Tricore.

# Title or name of your project
This example demonstrates the function of fast comparator. The threshold of fast comparator channel 0 is set to 2/VAREF, when the input voltage is beyond the threshold, the interrupt of FC occurs and P33.7 is toggled .
## Device
TC397XP
## Board
Board used for testing is TC397 Triboard
## Prerequisites
BIFACES tool and Taskig compiler
## Compiling
Import to Biface, modify the Tasking Compiler installation path for Tricore
### Infineon (optional)
add the infineon logo
! [Alt text](Readme_Files/infineon_logo.png?raw=true "Infineon logo ")

Please refer to the attached document for details

smartconx_target@Q!w2e3r4t5y6u7i8o9p0||/t5/%E4%BE%8B%E7%A8%8B/TC397XP-the-function-of-fast-comparator-%E5%BF%AB%E9%80%9F%E6%AF%94%E8%BE%83%E5%99%A8%E7%9A%84%E5%8A%9F%E8%83%BD/td-p/706117

I often need to create menus consisting of different number of items, and while the program is running, some items can be added and others removed, it creates confusion.
For example
1) previous page
2)...
3)...
4) next page
And here in the first page there is no item 1 and in the last page there is no item 4 and this has to be considered while entering the value.
I want to share a simple solution, it helped me a lot.

uint8   MenuSel (uint16 options,uint8 numel)
{
    uint8 count=0,result=1;
    while(options)
    {
        if(options & 1)
        {
            count++;
            if(count==numel) return result;        
        } 
        options>>=1;
        result++;
    }
    if(numel==0) return count;
    return 0;
}

It's easy to use:

for example this is a complete list of all possible options

//Menu create:

//1) other

//2) save item

//3) save group

//4) see items here

//5) back 

//6) no matter, exit now

//we only need to display options 3,6 uint8 menuset=0b100100;//exit+savegroup activate

//or add option 4     if(t2) menuset|=0b1000;//option 4 activate

//or remove option 4 if(t2) menuset &=~0b1000;//option 4 deactivate

            temp=1;
            do
            {
                temp1=MenuSel(menuset,temp);
                if(temp1)
                {
                    Printnum(temp);//Other
                    PrintMess(138+temp1,MessNext);//"other"
                }
                temp++;
            }while(temp1);
            numvars=Saynum(1,MenuSel(menuset,0),MessEnd);//Enter number from 1 to N

numvars is the number of the selected option from the full list,

PrintMess should output the text of the desired option from the list.

This code example provides a solution to the question, 'Did anyone enter your house while you were away?' The example uses the XENSIV™ DEMO BGT60TR13C 60GHz radar board and the presence_detection.py in the Radar Development Kit (RDK) with some minor modifications to allow you to receive notifications on your phone.

The example utilizes a programmable communication tool called 'Twilio'. Although there are many similar tools such as Sinch and Plivo available, the implementation process is quite similar.

To get started, create an account in Twilio using your email ID and password. Once this is done, you will receive a Twilio phone number from which the messages will be sent, an Account String Identifier (Account SID), and an Authentication token (Auth Token) to facilitate the process.

After creating a Twilio account, you need to follow these steps:

• Install the required Python wheels from the Radar Development Kit [radar_sdk\python_wheels].
• Open the presence_detection.py file from the Python examples [radar_sdk\examples\py\BGT60TR13C].
• Install the "twilio" package using "pip install twilio".
• Include the "twilio" package and the following code snippet at the beginning of the code:

Now, follow the steps below to send the presence status to your phone:

• Make the necessary modifications to the code using the following snippet:

• After making the changes, run the code to receive the message on your phone!

Upon detection of presence at your place, you will receive an SMS notification.

Hi,

Recently we see requests for examples in ModusToolbox.

So finally I decided to study MTB seriously.

This is my first trial of  writing SysTick timer sample with MTB.

To make the long story short, the following is my "main.c".
This will be enough for those who is/are comfortable with MTB.

/*******************************************************************************
* File Name:   main.c
*
* Description: This is the source code for a SysTick Timer
*              Example for ModusToolbox.
*
********************************************************************************
* (c) 2022-YEAR, Cypress Semiconductor Corporation. All rights reserved.
*******************************************************************************/

/*******************************************************************************
* Header Files
*******************************************************************************/
#include "cyhal.h"
#include "cybsp.h"
#include "cy_pdl.h"


/*******************************************************************************
* Macros
*******************************************************************************/
/*
 * To get a 1Hz interval, the number is same with the freq of ILO
 * Refer to "cy_sysclk.h"
 */
#define SYSTICK_TARGET_FREQUENCY (32768UL)

/*******************************************************************************
* Function Name: isr_tick
********************************************************************************
* Summary:
* This is the SysTick interrupt callback function.
*
* Parameters:
* None
*
* Return:
* NC
*
*******************************************************************************/
static void isr_systick(void)
{
    /* Invert the USER LED state */
    cyhal_gpio_toggle(CYBSP_USER_LED);
}


/*******************************************************************************
* Function Name: main
********************************************************************************
* Summary:
* Timer mode to generate the interrupt each 1s. Invert USER LED when interrupt
* generated.
*
* Parameters:
*  void
*
* Return:
*  int
*
*******************************************************************************/
int main(void)
{
    cy_rslt_t result;
    int slot ;

    /* Initialize the device and board peripherals */
    result = cybsp_init();
    /* Board initialization failed. stop program execution */
    if (result != CY_RSLT_SUCCESS)
    {
        CY_ASSERT(0);
    }

    /* Enable global interrupts */
    __enable_irq();

    /* Initialize the User LED */
    result = cyhal_gpio_init(CYBSP_USER_LED, CYHAL_GPIO_DIR_OUTPUT,
            CYHAL_GPIO_DRIVE_STRONG, CYBSP_LED_STATE_OFF);
    /* LED initialization failed. stop program execution */
    if (result != CY_RSLT_SUCCESS)
    {
        CY_ASSERT(0);
    }

    /* Setup SysTick and its callback */
    Cy_SysTick_Init(CY_SYSTICK_CLOCK_SOURCE_CLK_LF, SYSTICK_TARGET_FREQUENCY / 2) ;

    /* searching for an empty slot */
    for (slot = 0 ; slot < CY_SYS_SYST_NUM_OF_CALLBACKS ; slot++) {
    	if (Cy_SysTick_GetCallback(slot) == 0) {
    		break ;
    	}
    }

    if (slot < CY_SYS_SYST_NUM_OF_CALLBACKS) { // slot found!
    	Cy_SysTick_SetCallback(slot, isr_systick) ;
    } else { // no slot available >_<
    	CY_ASSERT(0) ;
    }

    Cy_SysTick_Clear() ;
    Cy_SysTick_EnableInterrupt() ;
    Cy_SysTick_Enable() ;

    for (;;)
    {
    }
    return 0 ;
}

And for those who is/are not comfortable with using MTB, aka MTB-phobia like me, the following steps were what I tried.

(1) First, start up MTB and specify the workspace.
This time I used "C:\infineon\MTB\Workspace240219_systick_test"
but as far as you follow the MTB's naming rule, you can use any workspace.

(2) The MTB WorkBench showed up.

(3)  From Menu: File > New > ModusToolbox Application

(4) Choose a BSP. Since I'm using CY8CPROTO-063-BLE, 
I chose 

PSoC 6 BSPs > CY8CPROTO-063-BLE

(5) Select Application
Although I myself used "Peripherals > HAL TCPWM Timer" to start with,
now we have "main.c" choosing "Getting Started > Empty App" will be fine and clean.
I also named the project "SysTick_Test".

(6) Now in the "Project Explorer" pain, "SysTick_Test" was created along with "mtb_shared".

(7) Unfold "SysTick_Test" folder and open main.c by double clicking the name.

And overwrite the content with the main.c above or attached.

(8) Then build the project by clicking the "hammer" icon or 
From menu:  Project > Build All

(9) Configure the debugger

I chose "GDB OpenOCD Debugging > SysTick_Test Debug (KitProg3_MiniProg4)"
Then select [ Debug ] button below.

(10) Debugger started.

If you select the "Resume" icon

hopefully the RED LED will start blinking every second.

moto

Edited: A typo correction and cover photo appended.

Run-time integrity checks are crucial in safety/security critical applications like in case of vehicle Electronic Control Unit (ECU). They help detect various security threats such as unauthorized modifications, or any tampering attempts which could potentially compromise the safety. These checks work during program execution. It verifies that the code and data being processed have not been altered or corrupted maliciously against the digitally signed hash  of the code being executed. 

Scope

This code example explains the usage of the functions available in TRAVEO^TM T2G MCU to do run-time integrity checks. The code was developed using the Sample Driver Library (provided by Infineon) and IAR Embedded Workbench for ARM® (EWARM) and its utilities.

Implementation

Flash Boot (FB) shared functions are a set of functions that can be executed from user code by pointing to specified memory locations where they are pre-defined.

They are:

1. Cy_FB_VerifyApplication: Function that is used to authenticate digital signature (RSASSA-PKCS1-v1.5) of data that is present in the flash. It can be called from any part of the code. If digital signature is valid, it returns true, else returns false.
2. Cy_FB_IsValidKey: Function that is used to validate whether the public-key loaded in the device for verifying digital signatures is of required public key format (Refer to section 34.3.4.2 in TRAVEO^TM T2G (TRM) for the RSA public key format). If valid it returns true, else returns false.

For this example, we use Flash Boot (FB)  shared function Cy_FB_VerifyApplication (For more information refer – section 34.2.1 of the TRM).

The example works as follow. We load 2 application images for CM4 each having a blinking LED code in them. The 2^nd CM4 application is the duplicate of the 1^st application. The CM0+ core periodically verifies the digital signature of the CM4 application image that is currently being executed, by calling Cy_FB_VerifyApplication function every 15 seconds. If the CM4 application (1^st application) integrity fails during run-time, the CM0+ requests for a system reset of MCU.

To fail the CM4 1^st application integrity check, we write garbage data over the CM4 1^st application address space by the CM0+ core. This is done at the end of the first 15 seconds. Thus, once after the system reset, the duplicate image of CM4 application (2^nd application) will be executed by CM0+, thus not fully compromising the system.

To visually verify the switch between the original (CM4s 1^st application) to duplicate image (CM4s 2^nd application) of CM4, the blinking . When CM4 1^st application is being executed the LED blinks for every 3 seconds and when CM4 2^nd application is being executed the LED blinks for every 0.3 seconds.

Both the CM4 applications (1^st and 2^nd application) are digitally signed using RSA signature scheme. The CM4 1^st application starts at 0x10080000 and ends at 0x10087FFF (32kB size). The CM4 2^nd application starts at 0x10088000 and ends at 0x1008FFFF respectively.  

The code was developed in IAR Embedded Workbench for ARMARM® (EWARM) with Sample Driver Library (SDL) in a TRAVEO^TM II Body Entry starter kit board. The CM4 applications have a fixed size of 32kB. This change along with few other changes are made in the default linker script available in the SDL.

To know more about how secured images for an application is generated and for placement and generation of the public-private key pairs that are required for the verification refer to the application note Secure system configuration in TRAVEO^TM T2G family and the CCE Published (Secure Boot in IAR environment)about Secure boot. The scripts included utilizes the existing IAR ielftool and the cymcuelf tool used uses Openssl.

The following points describe the working of the attached program files.

“main_cm0plus.c”:

1. Initialization of required macros and system is done.
2. Configuring the structure “cy_si_stc_public_key_t” for defining the public key and placement of the same in section “.sflash_app_prot” in SFLASH.
3. Enabling the CM4 core after verifying the CM4 application using the function “Cy_VerifySignature_CM4”.
4. Configure the TCPWM module to generate a 1 second delay. In the handler of the TCPWM interrupt, “Timer_Handler”, check if 15 seconds has elapsed. If so, write garbage data over the address space of CM4 1^st application (At 0x10081880).
5. Run-time integrity check of currently running application (1^st or 2^nd) by CM4. If integrity check fails set the variable    “errorIntr” to 1. If set, request for systemwide reset of the MCU.

“main_cm4.c”:

1. Initialization of macros and system is done.
2. Configuring the structure “cy_stc_si_appheader_t” and initializing it with the application header data as required and placing it in the section “.cy_cm4_app_header”.
3. Declaration of variable “cy_si_appSignature” in the section “.cy_app_signature” for populating digital signature of image by cymcuelf tool.
4. Basic blink LED code inside the main ().

Setting up of IDE for the code example:

1. Unzip the attachment and copy the contents into <PROJECT_DIR>\tviibe1m\src directory.
2. Replace the “linker_directives_tviibe_rev_d.icf” file in <PROJECT_DIR>\tviibe1m\tools\iar with the linker script file provided along with the code example.
3. Open the CM4 IAR workspace and attach the SB_CM4.bat script to it. For this, navigate to Project > Options > Build Actions > Post-build command line and attach the directory to the SB_CM4.bat script.
4. In the same menu, under Linker > Checksum, enable the Fill unused code memory option. Fill pattern will be 0x00, start and end address will be the CM4 applications start and end addresses respectively.

 Generating RSA public – private keys and CM4 signed images & dumping the images:

1. In the <PROJECT_DIR>\tviibe1m\src\utils, run the “rsa_keygen.bat” script. New public private key pairs would be generated inside the “keys_generated” folder. Inside the same, the file “rsa_to_c_generated.txt” has the public key as c structure. Copy this structure inside the “cy_si_stc_public_key_t” in the “main_cm0plus.c”. Ensure that the keys are generated first and copied into main_cm0plus.c before generating and dumping the CM4 applications.  
2. In the CM4 IAR workspace, to generate the
   1. CM4 1^st application:
      1. Under the Project>Options>Linker > Checksum in IDE, change the Fill pattern to 0x00 and start and      end address as the start and end addresses of the 1^st CM4 application i.e. 0x10080000 and 0x10087FFF.
      2. Clean and build the project once. Now you can dump the generated cm4.out file into the MCU using the IDE. The post build command bat script that has been attached will digitally sign the application using the private key file inside the “keys_generated” folder using the cymcuelf tool.
   2. CM4 2^nd application:
      1. In the linker script file “linker_directives_tviibe_rev_d.icf”, add an offset of 0x8000 in the symbol “_base_CODE_FLASH_CM4”.
      2.  In the same checksum menu as above, change the start and end address as the start and end addresses of the 2^nd CM4 application i.e. 0x10088000 and 0x1008FFFF. Also change the blinking rate in the main_cm4.c file to 0.3 seconds. Clean and build the project once. Now you can dump the generated cm4.out file into the MCU using the IDE.

1. In CM0+ IAR workspace, clean and build the project once and dump the main_cm0plus.out file.

Observation:

Once the CM0+ application is also dumped, restart the MCU. The LED will start to blink at a rate of 3 seconds for the first 15 seconds by the CM4 1^st application. Once 15 seconds has elapsed, CM0+ writes a garbage data over CM4 1^st application space. At the second 15 seconds, the integrity check fails for CM4 1^st application and hence CM0+ requests system wide reset. Thereafter CM4 2^nd application starts to be executed by CM4 core. The LED now will blink at rate of 0.3 seconds indicating the switch to the 2^nd application by the MCU.

Thus, by using the available FB shared function in TRAVEO^TM T2G MCU, we have done run-time integrity checks over the running CM4 application.

NOTE:

1. In this example we focus on CM4 applications, hence the CM0+ application is not authenticated by flash boot. The CM0+ application is of BASIC application format and both the CM4 applications are of the Cypress secured application format (Refer to section 34.3.4.1 in TRM).
2. By toggling the variable “CY_CM4_ERROR_INJ” to 0, error sequence written into 1^st CM4 application can be avoided.
3. It is not necessary for the CM4 application to be in cypress secured application format for verifying using the FB shared function.

Hi,

While ago, we had a discussion asking for charLCD sample for PSoC 6.

https://community.cypress.com/t5/PSoC-6-MCU/Display-LCD-on-PSOC-6/m-p/266274

And to my surprise, I could not find a charLCD component for PSoC 6 in PSoC Creator.

Adding on top this, the querist was showing 5V LCD in the block diagram,

so I suggested that he needs to use a 3.3V version to go with PSoC 6.

And if I had stopped there, I felt somewhat flighty, so I ordered "my" 3.3V LCD.

The good news is the parts arrived pretty soon,

but the bad news was I could not afford time to fight with it.

Finally, today, here is my first sample of charLCD like LCD control sample.

The schematic

The Pins

Tera Term log

For the command(s) please refer to the instruction of HD44780U Datasheet

Note: Sorry, I did not implement "read" function.

1-Mar-2021

moto

14-Oct-2021 Attached project updated

(1) Added delay before initializing the LCD

(2) When DB7 is high in writing,  clear DB7 after write phase is done to prevent the program from hang.

Secure boot is a boot process that ensures that only authenticated code is executed on the device. Secure booting typically involves authenticating the application flash images using a key-based security protocol defined by a market/application specific standard. In this code example, we will see how to configure the firmware to perform Secure Boot in TRAVEO™T2G MCU using IAR Embedded Workbench for ARM® (EWARM).

After reset, the ARM® Cortex® M0+ CPU starts executing from ROM boot. ROM boot validates SFLASH. After validation of SFLASH is complete, execution jumps to Flash boot and configures the DAP according to the protection state. The Flash boot then validates the first application present in the TOC2 structure and jumps to its entry point if it is valid. If the SFLASH or first application is found to be invalid or corrupted, the device will enter a DEAD protection state and stays in the DEAD protection state until the device is reset.

In this example, the TRAVEO™ T2G MCU's Flash Boot, which is first verified by ROM boot and guaranteed to be secure, verifies the CM0+ firmware. After booting, the CM0+ firmware verifies the CM4 firmware and enables only if the verification is successful. The board used in this example is CYTVII-B-E-1M-SK which consists of TRAVEO™ T2G CYT2B7 Series MCU. The code was developed in IAR Embedded Workbench for ARM® (EWARM) with Sample Driver Library (SDL).

Scope:

This code example demonstrates how to implement Secure Boot in TRAVEO™T2G MCU using the Sample Driver Library (provided by Infineon) and IAR Embedded Workbench for ARM® (EWARM).

Implementation:
For Secure Boot implementation, the device lifecycle stage must be transitioned to SECURE (where SFLASH rewriting is prohibited). Transition to SECURE life cycle stage is done by blowing secure eFuse bit. Before moving the device to SECURE life cycle, you need to update the TOC2, public key in the SFLASH region in NORMAL_PROVISIONED lifecycle stage.

1. Update Linker Scripts: Use the linker script “linker_directives_tviibe_rev_d.icf” provided in the zip file which contains required sections for the secure boot implementation.
2. TOC2 Configuration: The TOC2 is prepared as a constant table cy_toc2 in the main_cm0plus.c file, and must be placed at the specified address (0x17007C00) in the SFLASH. The following elements shall be configured in TOC2 :
   1. .cm0pappAddr1 : Address of the application to be verified by Flash Boot. In this example, the address of CM0+ firmware is specified.
   2. .cm0pappFormat1 : The format of the application. To make it verified by Flash Boot, this should be set as CYPRESS™ Standard format.
   3. .shashObj : This specifies the number of SFLASH regions which is verified by ROM boot when the device life cycle stage is SECURE or SECURE_W_DEBUG. To make the device SECURE, value should be atleast 3. The three elements are public key (located at 0x17006400; specified at .sigKeyAddr), SWPU objects (located at 0x17007600; specified at .swpuAddr), and TOC2 itself (located at 0x17007C00; specified at .toc2Addr).
   4. Asymmetric key preparation: Firmware authentication is done by verifying the digital signature populated at the end of the image as per the CYPRESS™ Standard format. Since digital signatures are generated using asymmetric private keys and verified using public keys, a set of asymmetric keys shall be prepared first.
3. In this example, we will use RSA-2048 public and private keys. Copy the files provided in the zip file to the $Installation_Directory$\T2G_Sample_Driver_Library_7.8.0\tviibe1m\src directory of the SDL library.
4. A batch script rsa_keygen.bat is included in utils folder which can generate the key pair and converts the public key to C structures. This batch script uses OpenSSL whose version is higher than 1.0.2, to generate RSA keyset, and also requires Python 3.x.x to convert RSA public key to C structures.
5. Placing public keys in SFLASH: The public key for verifying the firmware should also be populated in the SFLASH (0x17006400). Copy the public key generated (modulus and exponent) from utils\keys_generated\rsa_to_c_generated.txt  to the constant table cy_publicKey in main_cm0plus.c file.
6. CYPRESS™ Secure Application Format (CySAF) header: All the application code to be verified must be in CySAF format. File’s main_cm0plus.c and main_cm4.c contains its CySAF header as a table called cy_si_appHeader.
7. Adding digital signatures to the application: After building the project, the digital signature should be embedded to the generated elf file using private key. The batch scripts “SB_CM0+.bat” and “SB_CM4.bat” are provided in the zip file use cymcuelftool.exe to add digital signature. In IAR IDE Workspace, include these batch scripts in the post build command line. In IDE, navigate to Project -> Options -> Build Actions -> Post Build Command line and select the corresponding batch files provided in the zip file for the respective cores i.e., SB_CM0+.bat and SB_CM4.bat.
8. Booting CM0+ firmware: Once the elf file with the correct digital signature is flashed, the CM0+ firmware should be verified by Flash Boot and the CM0+ application starts executing.
9. Verifying CM4 firmware: CM4 firmware verification must be implemented by the user. In CM0+ application, the CM4 firmware is verified by using Flash Boot Shared function Cy_FB_VerifyApplication(). Please refer the section 38.2.1 of the Technical Reference Manual for the function description. If the verification is successfully, the CM4 application starts executing.
10. After code compilation, perform the following steps to program the device:
    
    1. Connect the Starter kit to your PC using the USB cable through the KitProg3 USB connector.
    2. Program the CM0+ and CM4 applications using Download option in IAR IDE.

Observation:

After programming, there will be two LEDs (LED 1 and LED 4) blinking at a different rate once CM0+ and CM4 applications are verified successfully. LED4 starts to blink after  CM0+ application is verified successfully by the Flash boot. LED1 starts to blink after CM4 application is verified successfully by the CM0+ application.

In case of failure of verification of CM0+ application, the LED4 will not blink and further the CM4 application verification will not be done. So, both the LEDs will not be blinking. In case of failure of verification of only CM4 application, the LED1 will not be blinking. If the CM0+ application verification is not successful, CM4 application authentication doesn’t happen.

Summary:

1. The device life cycle must be transitioned to SECURE for Secure Boot.
2. We have seen how we can implement Secure Boot in TRAVEO™T2G MCU using IAR Embedded Workbench for ARM® (EWARM).