Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

TRAVEO™ T2G Automotive Body Controller - FAQ – General - KBA232509

TRAVEO™ T2G Automotive Body Controller - FAQ – General - KBA232509

ChaitanyaV_61
Employee
Employee
50 questions asked 25 likes received 25 sign-ins

Home Page: TRAVEO™ T2G Automotive Body Controller - FAQ – CDC

1. General

 

1.1. How do I connect ADC output triggers to a TCPWM?

Generally, the ADC range violation trigger can be connected to the TCPWM Kill input so that when a violation occurs, the TCPWM is immediately stopped. See the “Trigger Multiplexer” section in the device datasheet to find the trigger multiplexer options applicable for the device. 1:1 trigger should be preferred over Mux Trigger because of the following reasons:

  • Using a Mux Trigger causes reduction in inputs and outputs; therefore, you cannot use it for all ADCs/PWMs.
  • Because a Mux Trigger which uses the ADC and TCPWM generic trigger can be used for other purposes, a 1:1 trigger is the more efficient use of resources.

You can use one of the following:

  1. One-to-one triggers:

This is the best option to connect the ADC output trigger to a TCPWM. Note that direct 1:1 trigger is present between specific ADC channel and TCPWM instances, so you must choose these instances carefully during schematic design. Additionally, TCPWMx_GRPx_CNTx_TR_IN_SEL0. STOP_SEL should be configured corresponding to the 1:1 trigger.

  1. Mux Trigger:

This is alternative option to configure range violation to TCPWM kill using the Mux Trigger, which supports connecting generic ADC trigger outputs to generic TCPWM trigger inputs. PASSx_SAR_TR_OUT_SELx. OUTx_SEL should be configured for the range violation trigger of a channel. At the TCPWM side, TCPWMx_GRPx_CNTx_TR_IN_SEL0. STOP_SEL should be configured with the appropriate generic trigger.

1.2. How do I start ADC conversions using TCPWM output triggers?

Generally, after the PWM cycle, ADC conversion can be triggered to measure the input voltage to the ADC which depends on the TCPWM signal. See the “Trigger Multiplexer” section in the device datasheet to find the trigger multiplexer options applicable for the device. 1:1 trigger should be preferred over Mux trigger because of the following reasons:

  • Using Mux Trigger causes reduction in inputs and outputs; therefore, you cannot use it for all ADCs/PWMs.
  • Because a Mux Trigger which uses the ADC and TCPWM generic trigger can be used for other purposes, a 1:1 trigger is the more efficient use of resources.

The following options support this:

  1. One-to-one triggers:

This is the best option for this use case. Note that the direct 1:1 trigger is present between specific TCPWM instances and the ADC channel, so you must choose these instances carefully during schematic design.

PASSx_SARx_CHx_TR_CTL.SEL should be configured to ‘1’ corresponding to the TCPWM 1:1 trigger. Additionally, TCPWMx_GRPx_CNTx_TR_OUT_SEL.OUTx should be configured for the required TCPWM event.

  1. Mux Trigger:

This is alternative option to configure the Mux trigger, which supports connecting TCPWM trigger outputs to generic ADC input inputs. PASSx_SARx_CHx_TR_CTL.SEL should be configured to the required generic trigger. At the TCPWM side, TCPWMx_GRPx_CNTx_TR_OUT_SEL.OUTx should be configured for the required TCPWM event.

1.3 .How do I pause the TCPWM block?

The TCPWM block can be paused when the CPU is halted. Do the following to support this feature:

  1. Set the Counter control register field TCPWMx_GRPx_CNTx_CTRL.DBG_FREEZE_EN to ‘1’ to freeze the TCPWM during debug.
  2. Set up the trigger multiplexer. For example, in CYT4BF devices, configure the Mux Trigger Group 9 to connect CPUSS:  CTI_TR_OUT to TCPWMx_DEBUG_FREEZE_TR_IN.
  3. Configure the Cross-Trigger Interface (CTI) in DAP. For example, the following code snippet can be used in CYT4BF devices:

#define TRC_CTICONTROL               (*((volatile uint32_t*)(0xE0080000)))

#define TRC_CTIINTACK                 (*((volatile uint32_t*)(0xE0080010)))

#define TRC_CTIINEN(n)                (*((volatile uint32_t*)(0xE0080020 + 4 * n)))

#define TRC_CTIOUTEN(n)               (*((volatile uint32_t*)(0xE00800A0 + 4 * n)))

TRC_CTIINEN(4) = 0x1; // "CM7_0 halted" routed to cross trigger matrix channel #

TRC_CTIOUTEN(6) = 0x1; // Cross trigger matrix channel #1 routed to sys.tr_cti_out[0]

TRC_CTICONTROL = 0x1; // Enable CTI

1.4. What is the behavior when there are more than two bits error on ECC memory?

ECC logic of Traveo II supports only Single Error Correction and Double Error Detection (SECDED); so, detecting more than two bits error cannot be guaranteed. SECDED requires a hamming distance of 4. When there is a one-bit flip, the error can be corrected 100% to the original value. When there is a two-bit error, it is possible to detect the error 100%, but there will be two possible correctable values; hence, error correction is not possible for two-bit error.  

Errors with more than two bits might be reported as non-correctable (multi-bit) ECC error. But, these errors might look like one-bit error for a different code word, and will be corrected to the same value (not the original value).

 1.5. Can BACKUP_BREGx contents be retained after software reset?

The BACKUP_BREGx registers are in the RTC system, and these register values are retained after software reset. According to the Architecture TRM (Traveo II Automotive Body Controller Entry Family Architecture TRM (002-19314) Section 19.1 Reset Sources), RTC is affected only by Power-On-Reset (POR). Therefore, if POR happens, the BACKUP_BREGx register values are not retained.

1.6. How can HyperRAM be connected to Traveo II Body High?

HyperRAM can be directly connected to Traveo II Body High device that is, pin-to-pin without series resister. Figure 1. HyperBus SPI Device 0 to SPIHB_DATA[7:0] shows the connection between shows the connection between Traveo II Body High device and HyperRAM.

For more details, see the Traveo II Automotive Body Controller High Family Architecture TRM.

Figure 1. HyperBus SPI Device 0 to SPIHB_DATA[7:0]

general.jpg

 

The SCK# pin exists only on 1.8 V HyperRAM device. In Figure 1. HyperBus SPI Device 0 to SPIHB_DATA[7:0], SCK# pin is connected to SPIHB_CLK_INV. However, this SPIHB_CLK_INV pin does not exist in Traveo II Body High device. So, SCK# pin can be opened on 1.8 V HyperRAM device.

Note that the corresponding SCK# pin on 3.0 V HyperRAM device is Reserved Future Use (RFU).

1.7. What are the precautions to be followed when using Socketed CPU board?

When using Socketed CPU board, make sure that:

  • ESD precautions are followed while operating and handling ICs.
  • The IC is placed with proper orientation.
  • The socket is top cover is properly aligned. The three dots on the socket cover need to be aligned with the Cypress logo in the EVK as shown in the following figure. Otherwise, there could be connectivity issues. The following figure is for CYTVII-B-E-1M-176-CPU board; however, it is applicable to other devices also. You will also find this alignment in the respective CPU boards’ user guide.

general1.jpg

1.8. Do different SMIF channels have different graphics performance?

No. The graphics performance is the same regardless of the SMIF channel used.

1.9. What is the reserved SRAM in memory map of CYTx devices?
  1. Reserved SRAM for internal access (not available for users, see the respective datasheet for more information). The newer revisions of the devices have first 2 KB of the SRAM reserved while the last 2 KB are reserved in the older revisions. The summary of silicon revision and reserved SRAM region mapping is shown below.
  2. a. Last 2 KB: CYT2B7 rev_a/rev_b/rev_c, CYT2B9 rev_a/rev_b, CYT4BF rev_a/rev_b, CYT4DN rev_a
  3. b. First 2 KB: CYT2B7 rev_d, CYT2B9 rev_c, CYT4BB rev_a,  CYT4BF rev_c, CYT4DN rev_b
  4. The SRAM area from (SRAM_MAX-6KB) to (SRAM_MAX-2KB) is used by Cypress firmware during boot operation. This area is available to the user, but data retention across resets is not guaranteed in this area, because it might be overwritten by Cypress boot firmware.
  5. ROM boot code clears  last 2 KB of SRAM to zero. This region is available after boot. However, data retention across resets is not guaranteed in this area.

 

0 Likes
974 Views