[FAQ] AM625 / AM623 / AM62A / AM62P / AM64x / AM243x Design Recommendations / Commonly Observed Errors during Circuit Optimization of Custom board hardware design

Hi Board designers, 

Here are some recommendations or care-about for Circuit Optimization of Custom board hardware design..

• Collaterals - Always use the latest collaterals on TI.com. A frequent check for updates on TI.com is recommended
• Schematics components and DNIs- Verify the voltage rating of the components used vs required voltage rating including derating. When reusing the SK schematics DNI configurations are cleared. Compare the DNI configuration with the PDF schematics and configure the DNIs as required.
• SD card IO voltage change LDO
  If IO voltage change circuit required for configuring SD card speeds are not implemented, It is recommended to use a fixed 3.3V IO power source
  and limit the operating speed to one of the 3.3V modes.
  https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_02_01_09/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Storage/MMC-SD.html?highlight=mmc#steps-for-working-around-sd-card-issues

• Limiting to SD HS speed mode can also be done by using the property no-1-8-v. This disable switching to 1.8V which is required for UHS speed modes(SDR104, DDR50, SDR50)
• &sdhci1 {
• /* SD/MMC */
• vmmc-supply = <&vdd_mmc1>;
• vqmmc-supply = <&vdd_sd_dv>;
• pinctrl-names = "default";
• pinctrl-0 = <&main_mmc1_pins_default>;
• ti,driver-strength-ohm = <50>;
• disable-wp;
• no-1-8-v; /* disabling all the UHS modes */
};

• SD card power supply load switch and load switch EN reset logic
• SD card pullup value recommendation 10K or more ?

From the noise immunity perspective, it is recommended to use a resistor value toward the lower end of the range defined for eMMC and SD Card.  Based on the use case ( preferred) it is Ok to stay toward the upper end to ensure the total pull value applied to the signal never drops below the min value defined in the specifications if software accidently turns on internal pulls for signals that have external pulls.

 Lower value pulls make it harder for noise to couple to the signal.  Noise coupling may not be a big concern for data signals, but could cause serious problems for clock signals.  The disadvantage is slightly higher power consumption during data transfers.  You must be careful and not go too low, where the DC current introduced by the pull resistor causes too much voltage drop in the output buffer when the signal is driven and the resulting signal swing is not pulled below VIL or above VIH.

Ensure internal pullups are not configured when 10K (improves noise immunity) external pullups are used.

• Concerns for not connecting any external terminations on unused signals (OSPI or SD Card or other IOs)
• Placement of pulls for OSPI and SD card
• ANDing logic for attached device reset
• Using RESETSTATz  to directly reset the memory and IO level compatibility
• Ppullups and pulldowns for OSPI interface IOs
• Pullups and pulldowns  for SD card interface IOs 
• Fail-safe operation - IOs operation and interface requirements 
• Connecting external IOs directly to the SOC inputs and adding External ESD protection
• Using an RC and Push Button for SOC reset inputs and Debouncing logic
• JTAG interface recommendations
• Crystal load and load capacitance selection for MCU_OSC0
• WKUP_LFOSC0 Crystal recommendations 

More recommendations and details for each of the recommendations will be updated on a continuous basis.

Regards,

Sreenivasa

Hi Board designers, 

Refer below additional recommendations.

• Concerns for not connecting any external terminations on unused signals (OSPI or SD Card or other IOs)

Internal pull resistors are weak and may not source enough current to maintain a valid logic level for some operating conditions. This can be the case when connected to components with leakage to the opposite logic level, or when external noise sources couple to signal traces attached to balls which are only pulled to a valid logic level by the internal resistor. Therefore, external pull resistors are recommended to hold a valid logic level on balls with external connections. 

Many of the device IOs are turned off by default and external pull resistors may be required to hold inputs of any attached device in a valid logic state until software initializes the respective IOs. The state of configurable device IOs are defined in the BALL STATE DURING RESET RX/TX/PULL and BALL STATE AFTER RESET RX/TX/PULL columns of the Pin Attributes table. Any IO with its input buffer (RX) turned off is allowed to float without damaging the device. However, any IO with its input buffer (RX) turned on shall never be allowed to float to any potential between VILSS and VIHSS. The input buffer can enter a high-current state which could damage the IO cell if allowed to float between these levels.

Without external pulls on the OSPI signals, the OSPI inputs will be floating from the time power is applied until the ROM boot configures the processor IOs. The floating inputs could put the OSPI device in an unexpected state that does unpredictable things to the data stored in the OSPI device during this period of time.  Floating inputs could also potentially damage the OSPI input buffers if the OSPI device is exposed to this condition for too much time over the life of the product.  This is definitely the case for the processor input buffers.  The processor input buffers must never be allowed to float even for short periods of time when the input buffer is enabled because the shoot-through current that flows from VDD through the input buffer to VSS can damage the input buffer when it is exposed to a mid-supply condition for too long.  This is why we do not allow any input signal to take longer than 1000ns to transition.  Even if the customer determines floating inputs will not damage the OSPI input buffers, allowing the chips select input to float would be a very bad design practice.  At least you do not need to worry with corrupted data if you have a pull-up that holds the OSPI device in its power-down state.

 The above description could be expanded to any attached device that is allowed to have floating inputs.

• Placement of pulls for OSPI and SD card  

 Many customer building core modules are placing the OSPI flash on the add-on (carrier) board. Customer do not place any pullups on the core board for the data signals. In some cases the power connector and the attach device interface connectors are different. Any suggestion for customers to follow.

Are you saying customers are designing a small PCB assembly with the processor and a few other components that gets plugged onto a bigger mother-board, where they are putting the OSPI device?

 If so, they must design the board to board connector such that the signals can transition from one board to the next without any impedance discontinuity. This means the power and grounds associated with the attached OSPI device needs to be in the same connector and assigned to pins such that the signals have a controlled impedance reference and the power/ground paths have low loop inductance with a small loop area. 

We have already discussed my concerns for not connecting any external terminations on unused signals.  The same applies here. refer above. 

 Regards,

Sreenivasa

Hi Board designers, 

Refer below additional recommendations.

VDD_CORE and VDDR_CORE are expected to be powered by the same source so they ramp together when VDD_CORE is operating at 0.85V. If they have separate rails for VDD_CORE and VDDR_CORE (sequenced as shown below) and just change the 0.75V to 0.85V, what issue will they run into?

The comment in the datasheet that says “VDD_CORE and VDDR_CORE are expected to be powered by the same source so they ramp together when VDD_CORE is operating at 0.85V” was included to steer the system designer toward a simple implementation when they were only planning to operate VDD_CORE at 0.85V.  It is not a firm requirement.

 Operating VDD_CORE and VDDR_CORE from separate 0.85V power sources is possible as long as the two power source solution never allows VDDR_CORE to be greater than VDD_CORE + 0.18V.  This is a firm requirement.

 There is a good chance the original design that uses separate power sources for VDD_CORE and VDDR_CORE will remain compliant to this requirement if it was compliant before changing VDD_CORE from 0.75V to 0.85V.  However, the system designer is responsible for confirming compliance to the requirement across all operating conditions.

Regards,

Sreenivasa 

Hi Board designers, 

Here are some guidelines that needs to be considered when selecting or designing the SOC power architecture

• Power supplies are configured to the required voltage level and are supplies are within the ROC
• Power architecture follows the power-up and power-down sequence as specified in the SOC data sheet
• Power architecture meets the slew rate requirements as specified in the SOC data sheet
• Ensure all the power supplies are available before the MCU_PORz is released
• Monitoring of all the supply rails
• Ensure the supplies are turned ON only after the voltage is below 0.3V (no residual voltage) after a power cycle
• The delay between the power supply ramp and the MCU_PORz high is as per the data sheet recommendations (9.5 ms min)
• The MCU_PORz slew is as minimum as possible to avoid internal reset circuit glitch

Regards,

Sreenivasa