Community Translation: リセットからのPSoC 6 MCUのスタートアップ時間の設定 – KBA232330
Version: **
After reset, the boot code is the first to run, which performs the following sequence of actions:
- Executes any hardware-specific initialization code.
- Verifies whether TOC2 (Table of Contents) in the user flash is valid.
- Gets the App0 Reset Handler.
- Configures the SWD/JTAG pins.
- Delays execution for a period of time (Wait Window / Listen Window).
- Launches the user application.
For more details on boot code, see the “Boot Code” chapter of the PSoC 6 Architecture TRM.
The timing diagram of the operations on reset is shown below:
Figure 1. Startup Timing Diagram (see PSoC 6 Programming Specifications)
Thus, the total startup time tstartup = tlite_up + tboot + tlisten
The following table lists the different time labels along with their values and operations done in that period (see PSoC 6 Programming Specification for these values):
|
Name |
Time Label |
Value |
Description |
|
Lite-up time |
tlite_up |
Max 250 µs |
Time from reset release until the CPU begins executing the boot code |
|
Boot-up time |
tboot |
0.7 – 600 ms |
Time taken for the operations done by the boot code from steps 1 to 4. |
|
Listen Window / Wait time |
tlisten |
20 ms (can vary between 0 – 100 ms) |
The default value for the listen window is to 20 ms (Step 5 of the boot code). It is used for connecting the programmers to enter programming mode. The MCU listens for the host to send the correct sequence of SWJ commands. |
You can create a simple application to toggle a pin in the CM0+ application to see how long it takes for the application to start after reset. Here’s a scope shot of the total time taken to execute the user application from reset:
The value is approximately 21 ms (values may vary). This startup time may not be suitable for applications that require the device to respond quickly after reset.
Why is the startup time around 21 ms?
You can observe that the majority of the time is contributed by the listen window (~20 ms).
In PSoC 6 MCU, the listen window is controlled by the TOC2 (Table of Contents). It is a data structure that provides information about the location of specific content in the user flash such as the security image, user application, and flash boot parameters. The detailed TOC2 format is shown below. See the “Boot Code” chapter of the PSoC 6 Architecture TRM for details:
To configure the listen window, modify bits 2:4 (LISTEN_WINDOW).
Note that if you set the listen window to 0 ms or change other bits (SWJ_PINS_CTL by disabling SWJ, for example), you will no longer be able to program the device again. Ensure that you change only the LISTEN_WINDOW bits.
Set the listen window to 1 ms, which should be suitable for most applications. In the attached projects, the TOC2 structure is modified to set the LISTEN_WINDOW to 1 ms (value = 2) using the FLASHBOOT_WAIT_1MS macro. The CY8CKIT-062-WIFI-BT kit was used for testing.
/** Flashboot parameters */
#define FLASHBOOT_FLAGS ((FLASHBOOT_VALIDATE_NO << TOC_FLAGS_APP_VERIFY_POS) \
| (FLASHBOOT_WAIT_1MS << TOC_FLAGS_DELAY_POS) \
| (FLASHBOOT_CLK_50MHZ << TOC_FLAGS_CLOCKS_POS))
/** TOC2 in SFlash */
CY_SECTION(".cy_toc_part2") __USED static const cy_stc_toc_t cy_toc2 =
{
.objSize = sizeof(cy_stc_toc_t) - sizeof(uint32_t), /**< Object Size (Bytes) excluding CRC */
.magicNum = 0x01211220, /**< TOC2 ID (magic number) */
.appAddr1 = 0x10000000u, /**< Application start address */
.tocFlags = FLASHBOOT_FLAGS, /**< Flashboot flags stored in TOC2 */
.crc = 0UL /**< CRC populated by cymcuelftool */
};
When the values of TOC2 are changed, the CRC value used to validate the TOC2 also needs to be updated. This is done automatically by the CyMCUElfTool when the build completes in PSoC Creator.
In ModusToolbox, add the following post-build command to the Makefile to sign the application to generate TOC2 CRC.
- Copy cymcuelftool.exe from the tools_2.x folder in your ModusToolbox installation directory and paste it inside the application directory (already done for you in the attached project).
- Edit this command to provide the absolute path to the application before performing the build.
POSTBUILD=./cymcuelftool.exe --sign "<path_to_application>/mtb-psoc6-reduce-startup-time/build/CY8CKIT-062-WIFI-BT/Debug/mtb-psoc6-reduce-startup-time.elf" --output "<path_to_application>/mtb-psoc6-reduce-startup-time/build/CY8CKIT-062-WIFI-BT/Debug/mtb-psoc6-reduce-startup-time.elf" --hex "<path_to_application>/mtb-psoc6-reduce-startup-time/build/CY8CKIT-062-WIFI-BT/mtb-psoc6-reduce-startup-time.hex"
The archive attached contains both the ModusToolbox and PSoC Creator projects.
- ModusToolbox project: Toggles pin 10.1 in the CM4 application and sets the listen window to 1 ms. It uses the pre-built CM0p image.
Because the CM0p application is the one that starts first, you can use the dual-CPU application template and toggle the pin in the CM0p application. This will provide more accuracy because there is usually a few microseconds delay between the start of CM0p to CM4 based on when the CM4 application is started from the CM0p application.
- PSoC Creator project: Toggles the pin 10.0 and 10.1 in the CM0p and CM4 applications respectively, and sets the listen window to 1 ms.
Connect the logic analyzer and press the reset switch on the kit. You should see the startup time from XRES to CM0p executing the application to be around 2 ms, which is a major improvement from 21 ms.
For the ModusToolbox application, you can take the reading from the reset to the start of the CM4 application.
The project contains other macros that you can experiment with. Note that incorrect values may make your device inoperable.
Here’s the scope shot for different values of the macro:
FLASHBOOT_WAIT_20MS:
FLASHBOOT_WAIT_10MS:
