Code Examples Forum Discussions
Hi,
Recently I saw a question about GPIO interrupt PSoC 5LP.
https://community.infineon.com/t5/PSoC-5-3-1/Interruption-always-active/m-p/444159#M49243
There I posted a simple sample, but just in case some others who are new to PSoC 5LP,
this sample may be useful, so I'm posting this here with some clean ups.
To make the sample simple, I used the push button on the board SW1 as the GPIO input,
and the LED1 on the board as output. And the value for LED1 is 0 (OFF) and 1 (ON),
which usually I'd like to define as below, but without this I could save 2 lines 😜
#define LED_ON 1u
#define LED_OFF 0u
I used CY8CKIT-059.
Schematic
SW1 configuration
(General)
(Input) Note: Interrupts: Falling edge
LED1 config Note: Initial drive state: Low (0)
Pins
main.c
#include "project.h"
volatile int sw1_flag = 0 ; /* SW2 pin pushed flag, note "volatile" */
CY_ISR(sw1_isr)
{
SW1_ClearInterrupt() ; /* First clear interrupt flag of the pin */
sw1_flag = 1 ; /* Flag that SW2 pin was pushed */
}
int main(void)
{
CyGlobalIntEnable; /* Enable global interrupts. */
int_sw1_ClearPending() ; /* Clear Pending interrupt, may be not necessary */
int_sw1_StartEx(sw1_isr) ; /* Start pin interrupt with sw2_isr as the ISR */
for(;;) {
if (sw1_flag) { /* SW1 was pushed */
sw1_flag = 0 ; /* First clear interrupt flag */
if (LED1_Read() == 0) { /* LED1 is OFF now */
LED1_Write(1) ; /* Turn LED1 ON */
} else { /* LED1 is ON now */
LED1_Write(0) ; /* Turn LED1 OFF */
}
}
}
}
moto
Show Less
Description Overview
Attached project outputs the following signals
1. PWM signal (2) that rises with a fixed time delay relative to the rising and falling edge of the PWM signal (1)
2. (1) Period = (2) Period × 2
Required Environment
• Evaluation board: KIT_A2G_TC364_5V_TRB_S (Starter Kit containing TC364 Triboard, using LQFP version )
• IDE name: ADS 1.5.4
• Oscilloscope
• ADS project attached below
procedure
1. Connect oscilloscope probes to P13.2 and P13.0.
2. When the project attached to this page is operated, the waveforms shown in the image below can be observed.
supplementary information
• Project created according to the requirements of the following site
https://community.infineon.com/t5/AURIX/Synchronize-ATOM-modules/mp/409586#M11769
• As shown in the figure below of the UM, each CH in the ATOM operates using the same clock, so the outputs are synchronized.
Show Less
Provided below is custom implementation of the 10-bit current DAC (DIDAC10) for PSoC4. Component uses dithering technique by rapidly modulating the LSB of the IDAC8, providing effective (averaged) 10-bit output resolution. Component doesn't provide true 10-bit resolution, limited by the INL of the underlying IDAC8. The component implementation is similar to the stock dithered voltage DVDAC component for PSoC5.
Component can be used whenever tunable voltage source is needed, such as DC control voltage, voltage scan source or slow modulation source.
Component is compatible with PSoC4 and was tested using CY8CKIT-044 PSoC4M Pioneer Kit. Several demo projects are provided. Component is not compatible with PSoC5.
Component major features:
Effective (dithered) 10-bit resolution
Current range 0.3uA/bit or 0.6uA/bit
Current source, sink or bipolar options
Dithered using DMA for zero CPU overhead
Uses single IDAC8 block
Attached archive contains component library, component datasheet and several demo projects for PSoC4. Please read installation instructions in the readme.txt.
The component provided as-is, no liabilities. It is free to use and modify.
Figure 1. Basic demo schematic. The DIDAC10 is configured as current source 0.3uA/bit , loaded on the external 3.3k resistor. A 6nF capacitor is added to filter out the ripple.
Figure 2. Scope trace. When DAC code is scanned in the range [0 to 1020], the output varies from 0 to 1V.
Show Less
Dears,
please find my tentative approach to ECC Parity Calculation in the file attached. The code is based on the algorithm given in the TRM, section Code Flash/Flash Controller.
The code gives you the functions ECC64_parity(uint64_t data) and ECC32_parity(uint32_t data). The return values can be used in the call to Cy_Flashc_InjectECC(cy_en_region_t region, uint32_t address, uint8_t parity) from module cy_flash.c.
The presented code is for educational purposes only. It is not tested. Expect errors. Do not use it in a real application but write your own and test this.
Should you find this posting helpful please click Thumbs-Up.
BR
JJack
Show LessQuestion: How a GATT Client can discover all the Services, Characteristics and Descriptors in GATT Database with PSoC4 BLE device?
Answer: BLE Central device (GATT Client role) can discover all the services, characteristics and descriptors on a GATT Server (peripheral in majority of cases), to which it is connected using the CyBle_GattcDiscoverAllPrimaryServices(), CyBle_GattcDiscoverAllCharacteristics() and CyBle_GattcDiscoverAllCharacteristicDescriptors() APIs.
CyBle_GattcDiscoverAllPrimaryServices() API is used to discover all the primary services on a GATT Server as per the handle-range provided. CyBle_GattcDiscoverAllCharacteristics() API is used to discover all the characteristics in a service on a GATT Server when the service handle range is known. CyBle_GattcDiscoverAllCharacteristicDescriptors() API is used to find all the characteristic descriptors when the attribute handle range is known.
Objective:
This example demonstrates how a GATT Client can discover services, characteristics and descriptors on a GATT server Database device with PSoC4 BLE Device.
Overview:
In this example project, BLE component is configured in GAP Central role. Initially, device will scan and connect to the peer device which is advertising with desirable peripheral device address. After the device gets connected to the peripheral, central device will discover all the services, characteristics and descriptors and prints their Attribute handles, UUIDs etc. through UART using a terminal application (like TeraTerm).
Requirements:
Design Tool: PSoC Creator 4.4 or later.
Programming Language: C (GCC 4.8.4 – included with PSoC Creator)
Associated Devices: All PSoC 4 BLE devices
Required Hardware: CY8CKIT-042-BLE-A Kit
PSoC Creator Schematic:
Figure1: PSoC Creator Schematic- PSoC 4 BLE GATT Client Discovery.
Project Description:
In PSoC4 BLE Central project, in main() function, CyBle_Start(StackEventHandler) function is called to start the BLE Component and register a callback to the stack event handler. On successful stack initialization, CYBLE_EVT_STACK_ON is received and CyBle_GapcStartScan(CYBLE_SCANNING_FAST) function is called to discover GAP peripheral devices. As soon as the discovery operation starts, CYBLE_EVT_GAPC_SCAN_START_STOP event is generated. The event CYBLE_EVT_GAPC_SCAN_PROGRESS_RESULT will be generated when Discoverable GAP peripheral devices are located. After checking with valid Device address of the GAP peripheral, the GAP central device stops scanning and send a connect request to the peripheral.
After connecting with the device, CyBle_GattcDiscoverAllPrimaryServices() function is called to discover all the primary services on a GATT Server( peripheral in present case) to which it is connected. Internally, this function initiates multiple Read By Group Type Requests to the peer device, in response to which it receives Read By Group Type Responses. Each Read By Group Type Response results in CYBLE_EVT_GATTC_READ_BY_GROUP_TYPE_RSP event. Start handle, End handle, UUID values of the services will be displayed in the TeraTerm.
After discovering all the services, reference project asks to enter character ‘c’ or ‘C’ for discovering the characteristics in a service. After entering the character, user has to enter the service number (numbers should be entered in two-digit format like 01,02,03….) to discover all the characteristics present in that service. CyBle_GattcDiscoverAllCharacteristics() API is used to discover all characteristics within a service on a GATT Server when the service handle range is known. Internally, multiple Read By Type Requests are sent to the GATT Server, in response to which Read By Type Responses are received. Each response results in the event CYBLE_EVT_GATTC_READ_BY_TYPE_RSP. Characteristic declaration Handle, Characteristic Properties, Characteristic Value Handle and Characteristic UUID values of all the characteristics present in that service will be displayed in the TeraTerm.
After discovering all the characteristics, reference project asks either to enter character ‘d’ or ‘D’ for discovering the descriptors in a characteristic number or to enter character ‘c’ or ‘C’ for discovering the characteristics present in other services. If user enters character ‘d’ or ‘D’ followed by the characteristic number (numbers should be entered in two-digit format like 01,02,03….), then the client device will starts discovering all the characteristic descriptors present in that characteristic. CyBle_GattcDiscoverAllCharacteristicDescriptors() API is used to discover all the descriptors in a characteristic when the attribute handle range is known. Internally, multiple Find Information Requests are sent to the peer device, in response to which Find Information Responses are received at the GATT Client. Each of these responses generate CYBLE_EVT_GATTC_FIND_INFO_RSP event at the GATT Client end. Descriptor Handle, Descriptor UUID format and Descriptor UUID values of all the descriptors present in that characteristic will be displayed in the TeraTerm.
Steps to Test the project:
- Open UART Terminal and the select the COM port (related to PSOC4 BLE device) and use the following settings:
Baud rate:115200
Data rate: 8 bit
Parity: none
Stop: 1 bit
Flow control: none
- After programming the PSoC4 BLE Central, device will start to scan. Among the received peripheral devices, if the peripheral device address matches with 0x00A050000003 address then the central device will connect automatically. After the connection got established, client device discovers all the services present in the GATT database. Discovered services will be displayed in the TeraTerm as shown in Figure 2.
Figure 2: List of services displayed in UART Terminal.
- Enter character ‘c’ or ‘C’ followed by the service number to discover all the characteristics present in that service. List of characteristics will be displayed as shown in Figure 3.
Figure 3: List of characteristics displayed.
- Enter character ‘d’ or ‘D’ followed by the characteristic number to discover all the descriptors present in that characteristic. List of characteristic descriptors will be displayed as shown in Figure 4.
Figure 4: List of descriptors displayed.
Conclusion:
Central project (GATT Client) is successfully developed and verified with the PSoC4 BLE Device, and the expected results are observed. Central GATT Client project is attached with this document.
Show LessQuestion: How a GATT Client can discover all the Services, Characteristics and Descriptors in the Peripheral GATT Database with PSoC6 BLE device?
Answer: BLE Central device (GATT Client role) can discover all the services, characteristics and descriptors on a GATT Server (peripheral in majority of cases), to which it is connected using the Cy_BLE_GATTC_DiscoverPrimaryServices(), Cy_BLE_GATTC_DiscoverCharacteristics() and Cy_BLE_GATTC_DiscoverCharacteristicDescriptors() APIs.
Cy_BLE_GATTC_DiscoverPrimaryServices() API is used to discover all the primary services on a GATT Server as per the handle-range provided. Cy_BLE_GATTC_DiscoverCharacteristics() API is used to discover all the characteristics in a service on a GATT Server when the service handle range is known. Cy_BLE_GATTC_DiscoverCharacteristicDescriptors() API is used to find all the characteristic descriptors when the attribute handle range is known.
Objective:
This example demonstrates how a GATT Client can discover services, characteristics and descriptors on a GATT server Database device with PSoC6 BLE Device.
Overview:
In this example project, BLE component is configured in GAP Central role. Initially, device will scan and connect to the peer device which is advertising with desirable peripheral device address. After the device gets connected to the peripheral, central device will discover all the services, characteristics and descriptors and prints their Attribute handles, UUIDs etc. through UART using a terminal application (like TeraTerm).
Requirements:
Design Tool: PSoC Creator 4.4 or later.
Programming Language: C.
Associated Devices: All PSoC 6 BLE devices.
Required Hardware: CY8CKIT-062-BLE Pioneer Kit.
PSoC Creator Schematic:
Figure1: PSoC Creator Schematic- PSoC 6 BLE GATT Client Discovery.
Project Description:
In PSoC6 BLE Central project, BLE Component is configured in dual role where controller on cmo+ and Host and profiles on cm4. In HostMain() function, Cy_BLE_Start(StackEventHandler) function is called to start the BLE Component and register a callback to the stack event handler. On successful stack initialization, CY_BLE_EVT_STACK_ON is received and Cy_BLE_GAPC_StartScan() function is called to discover GAP peripheral devices. As soon as the discovery operation starts, CY_BLE_EVT_GAPC_SCAN_START_STOP event is generated. The event CY_BLE_EVT_GAPC_SCAN_PROGRESS_RESULT will be generated when Discoverable GAP peripheral devices are located. After checking with valid Device address of the GAP peripheral, the GAP central device stops scanning and send a connect request to the peripheral.
After connecting with the device, Cy_BLE_GATTC_DiscoverPrimaryServices() function is called to discover all the primary services on a GATT Server( peripheral in present case) to which it is connected. Internally, this function initiates multiple Read By Group Type Requests to the peer device, in response to which it receives Read By Group Type Responses. Each Read By Group Type Response results in CY_BLE_EVT_GATTC_READ_BY_GROUP_TYPE_RSP event. Start handle, End handle, UUID values of the services will be displayed in the TeraTerm.
After discovering all the services, reference project asks to enter character ‘c’ or ‘C’ for discovering the characteristics in a service. After entering the character, user has to enter the service number (numbers should be entered in two-digit format like 01,02,03….) to discover all the characteristics present in that service. Cy_BLE_GATTC_DiscoverCharacteristics() API is used to discover all characteristics within a service on a GATT Server when the service handle range is known. Internally, multiple Read By Type Requests are sent to the GATT Server, in response to which Read By Type Responses are received. Each response results in the event CY_BLE_EVT_GATTC_READ_BY_TYPE_RSP. Characteristic declaration Handle, Characteristic Properties, Characteristic Value Handle and Characteristic UUID values of all the characteristics present in that service will be displayed in the TeraTerm.
After discovering all the characteristics, reference project asks either to enter character ‘d’ or ‘D’ for discovering the descriptors in a characteristic number or to enter character ‘c’ or ‘C’ for discovering the characteristics present in other services. If user enters character ‘d’ or ‘D’ followed by the characteristic number (numbers should be entered in two-digit format like 01,02,03….), then the client device will starts discovering all the characteristic descriptors present in that characteristic. Cy_BLE_GATTC_DiscoverCharacteristicDescriptors() API is used to discover all the descriptors in a characteristic when the attribute handle range is known. Internally, multiple Find Information Requests are sent to the peer device, in response to which Find Information Responses are received at the GATT Client. Each of these responses generate CY_BLE_EVT_GATTC_FIND_INFO_RSP event at the GATT Client end. Descriptor Handle, Descriptor UUID format and Descriptor UUID values of all the descriptors present in that characteristic will be displayed in the TeraTerm.
Steps to Test the project:
- Open UART Terminal and the select the COM port (related to PSOC6 BLE device) and use the following settings:
Baud rate:115200
Data rate: 8 bit
Parity: none
Stop: 1 bit
Flow control: none
- After programming the PSoC6 BLE Central, device will start to scan. Among the received peripheral devices, if the peripheral device address matches with 0x00A050AABBFF address then the central device will connect automatically. After the connection got established, client device discovers all the services present in the GATT database. Discovered services will be displayed in the TeraTerm as shown in Figure 2.
Figure 2: List of services displayed in UART Terminal.
- Enter character ‘c’ or ‘C’ followed by the service number to discover all the characteristics present in that service. List of characteristics will be displayed as shown in Figure 3.
Figure 3: List of characteristics displayed.
- Enter character ‘d’ or ‘D’ followed by the characteristic number to discover all the descriptors present in that characteristic. List of characteristic descriptors will be displayed as shown in Figure 4.
Figure 4: List of descriptors displayed.
Conclusion:
Central project (GATT Client) is successfully developed and verified with the PSoC6 BLE Device and the expected results are observed. Please find the below attached Central project.
Show LessHi,
I'm a big fan of Infineon's UART component. I use the UART component (UART_v2_50) on 90% of my projects I tend to use it in 8N1 mode. I have no issues with it in this mode.
However in a recent project I've been requested to work on, it uses MARK and SPACE parity in the data across a proprietary LAN to signal all clients special information.
Sadly, I have found that selectively transmitting MARK or SPACE on specific bytes of the packet transmission not to be working correctly. SPACE parity is the default parity. I can get it to output MARK parity but not reliably or predictively.
I have asked on two other threads about receiving an example project from others about a successful MARK/SPACE parity control. Aside from help from @BiBi_1928986, I've read about others unsuccessful attempts as I achieved. @BiBi_1928986 provided an example project with a complicated circuit to get around a "logic" issue with the UART_v_2_50 implementation.
To solve this issue in a more 'elegant' (and reliable) solution, I have created my own UART_Tx component with proper MARK/SPACE control on a byte-for-byte basis.
I looked at 'fixing' the UART_v2_50 component. This was not going to happen anytime soon. If you look behind the 'curtain' on this component, you will find it VERY, VERY, VERY complicated. It has a lot of "bells and whistles" of features to support the ancient UART format along with the modifications that industry has added to it over time.
My component UART_SMTx_v1_00 is a "no-frills" component. It has the following features and lack of features:
- UART Tx only. No Rx is supported. I found the UART_v2_50 works to detect Rx MARK/SPACE parity correctly.
- The mode supported is (8MS1) 8-bit data, MARK/SPACE parity, 1 START bit and STOP bit. See the next note.
- The component was designed using the UDB Editor. All the editor design content is included in case you wanted to study or modify it to your needs. For example, it would be fairly simple to change the data size, the number of STOP bits, etc.
- UART API functions (Tx-only blocking and non-blocking) are modified to include a parity parameter. This is to provide familiar API functions with similar functionality.
- Each UDB has two 4-byte FIFOs. My version of the component uses BOTH FIFOs. One is used for the data and the other for the desired parity. The two FIFOs are loaded in sync with one another to correctly control the desired parity to the byte. Therefore the blocking and non-blocking UART API functions have been updated with a parity parameter and can be safely queued 4-deep for efficient CPU/application processing. In theory, with correct loading of the FIFOs (parity first then the data last), DMA can be used. Note: This is an improvement over the intended UART_v2_50 implementation.
- If you have a data array over 4 bytes, use the PutArray() function for blocking or the WriteTxData() with ReadTxStatus() validation for non-blocking.
- I've provided a Tx_En output for half-duplex or LAN peer-to-peer multiplexing.
- I've provided a SW selectable interrupt output based on TX_COMPLETE, FIFO_EMPTY, FIFO_NOT_FULL and FIFO_FULL status.
- Since this component is 'hardcoded' all the parameters are read-only.
- I have no component datasheet. However, I have tried to reasonably comment the UDB editor file and the .c and .h files.
- I have attached a simple demo project that alternates between a polled (blocking) and interrupt (non-blocking) implementation of transfer of a short set of data and parity.
- In the demo, I send 10 bytes with selected MARK or SPACE parity. I have included the Infineon UART component to read the transmitted data. The debugger output to a terminal program displays the data along with the parity detected ('_' prior to the hex data => SPACE ... OR ... hex data without a preface char => MARK.
- The project was built on a CY8CKIT-059 but can be run virtually any PSoC5LP or PSoC3. (The PSoC3 may require some minor modifications and have not been tested).
- The component files are included in the project itself. It is included in a directory called "UART_SMTx_v1_00". This simplifies incorporating the component into a new project. Just drop the entire directory into your new project.
This project is free for your use in your project. (No warranty is expressed or implied) You can modify it if needed.
If you have any problems or have suggestions, please post to this forum thread.
Show LessI have posted this sample code as one of the protection control example using the Firmware API.
[Overview]
You can confirm the followings using this sample code :
1, You can easily enable/disable D-Flash read/write protection parmanently by key=0 and key=1 commands.
2, You can confirm temporary protection/un-protection usage by key=2 and key=3 commands.
3, You can check that you can’t write D-Flash data while D-Flash R/W protection is enabled using #4 and #5 commands.
4, You can show the current protection status by key=7 command.
[Environment]
Confirmed evaluation boards :
1) TLE984x Evalboard
2) TLE9844-2QX Application Kit
IDE :
1)uVision V5.38.0.0
Software :
1) TLE984x_FW_API_Protection_v0.zip
[Usage of this software]
1, Program this software into the TLE984x of the evaluation board
2, Connect your PC and an evaluation board by USB cable
3, Lunch a terminal software and set 115200bps
4, Push RESET-SW of your evaluation board, then terminal software shows the following menu. Please follow the menu.
If you want to try Mass-erase function using a wrong password, please comment out line 85 of main.c of the below.
Line 85 //#define MASS_ERASE_ENABLE;
Caution : If you perform the mass-erase (Key=b) function, you need uIO Stick for full recovery.
[TEST example]
// You can confirm that your TLE984x will be protected and can’t connect with your debugger like a uVISION.
step 01 Press Key= 7 : Show protect status. (unlock status)
step 02 Press Key= 0 : Set permanent D-Flash read and write protection.
step 03 --- push RESET-switch on your evaluation board. ---
step 04 Press Key= 7 : Show protect status. (lock status)
// You can confirm that R/W protected D-Flash can’t write by FW-API.
step 05 Press Key= 8 : Show D-Flash memory data.
step 06 Press Key= 4 : Write D-Flash, but you can’t. (data pattern 0x30,0x31,0x32,0x33... )
step 07 Press Key= 8 : Show D-Flash memory data.
// You can write to the protected D-Flash memory with pre-temporary clear protection (unlock status).
step 08 Press Key= 3 : Clear D-Flash read and write protection temporary.
step 09 Press Key= 7 : Show protect status. (unlock)
step 10 Press Key= 4 : Write D-Flash. (data pattern 0x30,0x31,0x32,0x33... )
// You can confirm the temporary unlock status will be canceled by RESET.
step 11 --- push RESET-switch on your evaluation board. ---
step 12 Press Key= 7 : Show protect status. (lock status)
// You can clear permanent D-Flash read and write protection after RESET. And you can write D-Flash.
step 13 Press Key= 1 : Clear D-Flash read and write protection permanently.
step 14 --- push RESET-switch on your evaluation board. ---
step 15 Press Key= 7 : Show protect status. (unlock status)
step 16 Press Key= 5 : Write D-Flash. (data pattern 0x00,0x01,0x02,0x03... )
For step 13, Key=9 or Key=a can be used inserted of Key=1. The result is the same.
Show LessHi,
iMOTION2go is pre-programmed with the latest version of the iMOTION™ firmware and the script-based demo which is running the small motor mounted on the board. As soon as the kit is powered up through the USB slot, the demo will start and periodically vary the speed of the motor and alternate its rotating directions.
But the .zip file iMOTION2Go Software Package is for MCEWizard and MCEdesigner.
I posted the software package for the brand new tool iMOTION Solution Designer (iSD)
- install iSD
- Download the zip file and extract it
- Open iSD and File -> Open Project -> Select "i2023_01_24 iMOTION2Go.cwproj"
Regards,
Kazu Hayashi
I have posted this sample code to check the waveform of the RESET pin and the values of the registers affected by WDT1 RESET/ SYS_FAIL RESET.
[Overview]
Using this sample code, you can see the following :
1, You can check the SYS_FAIL RESET period by your oscilloscope.
2, You can check the WDT1 REST by your oscilloscope.
3, You can check value of both PMU_RESET_SYS and PMU_WFS registers by the terminal software on your PC.
[Environment]
Confirmed evaluation boards :
1) TLE984x Evalboard
2) TLE9844-2QX Application Kit
IDE :
1)uVision V5.38.0.0
Software :
1) UART2_TTY_EXAMPLE_TLE984x_WDT1.zip
[Instructions]
1) Program this software into your evaluation board via uVision.
2) Execute any terminal software on your PC (ex. TeraTerm) and connect it with evaluation board at 115200bps.
3) Push RESET-SW on the evaluation board.
Then, you can see the register values by terminal software and RESET-pin pulse by oscilloscope, every RESET timing.
[Result]
1, SYS_FAIL RESET waveform :
You can see a 1sec of Fail Sleep period. Please refer to the waveform in the left.
2, WDT1 REST waveform :
In this code, WDP_SEL=0x3F(1.008sec). So, you can see 4 times of 32us glitch pulse. Please refer to the waveform in the bottom right. And the 5th time, Fail Sleep RESET can be confirmed.
About WDT1 RESET pulse :
I was surprised because I haven’t noticed that there is a RESET mode which RESET-pin will not be asserted.
WDT1 (Watchdog) RESET is that one. And I coudn7t find out such an explanation in the UM v1.3.
By the way, explanation of TLE987x UM v1.8 is almost same.
However, we have observed on the oscilloscope that the TLE987x does not assert the RESET pin at all when WDT1 occurs.
About SYS_FAIL RESET pulse :
TLE987x_UM has the following sentence.
However, there isn’t any explanation why the waiting time is 1 sec.
TLE987x_UM, Rev1.8, p22,
Sleep mode is activated after 5 consecutive watchdog failures or in case of supply failure (5 times). In this case,
MON is enabled as the wake source and cyclic wake-up is activated with 1 s of wait time.
There is no such statement in TLE984x UM v1.3, but I guess the same from my measurement results.
And about 1sec of the wait time, TLE987x_UM and TLE984x_UM have no description.
However, I think the SYS_FAIL period can be calculated with the default value of the PMU SLEEP register.
The off-time of the Cyclic mode is calculated to be 1.024 sec.
3, Value of both PMU_RESET_SYS and PMU_WFS registers of every RESET:
You can see the value of both registers as the below.
If you have any feedback, please let me know.
Thank you.
Hiro
Show Less