Tool/software:
Hi TI Experts,
Please share your inputs on processor core, thermal alert, VDD_CORE, VDDR_CORE, VPP and other supplies
Please share any available information related to the cores that can be used during custom board design
Hi Board designers
Thank you for the interest.
Inputs related to OPP
Data Sheet:
The OPP is mostly a function of software. However, the operating frequencies defined in an OPP may or may not be based on hardware imitations. This depends on the clock in question. For example, many of the modules have clock frequency ratios requirements that must be maintained between clock domains for proper operation. So it is not possible to simply change a module’s operating frequency without considering these limitations.
The table is defining what we have internally agreed to support as valid operating points since we do not allow customers to change operating frequency of the various modules. Allowing customers to change frequencies outside of these OPPs would require us to define the clocking limitations of every module. In most cases these limitations have multiple dependencies which can be very difficult to define. In the past we have found this approach is problematic as customers may not fully understand and check the limitations. This results in the customer configuring the device to invalid operating condition. So we simplified the number of options supported by defining specific OPPs.
No, that pretty much sums it up.
For example, even though the processor core can technically operate from across a wide frequency range, we didn’t want to give the customer free reign on picking any operating frequency. OPPs are finite voltage/frequency operating points that the customer can choose from. These have been tested by software over the years, so there’s really no reason for a customer to deviate from these.
I see the below in the data sheet
FIXED OPERATING FREQUENCY OPTIONS (MHz)(2)
(2) Fixed operating frequency, set by software at boot
and TRM
6.2.3 Power Management Techniques
The following section describes the power management techniques supported by the device
6.2.3.1 Dynamic Frequency Scaling (DFS)
DFS is a power management technique where the operating frequency is dynamically scaled across device
Operating Performance Points (OPP). An OPP is a voltage/frequency pair that defines a specific power state.
For each OPP, software controls clock frequency in order to adjust the performance and power to the optimum
point. The Device supports DFS for Cortex-A53 only.
6.2.3.2 OPP Low
The device supports lower bus frequency operation as OPP Low. The OPP Low must be configured at boot time.
In OPP Low, the main CBASS clock frequency is reduced in half in order to lower active power consumption with
reduced performance. The performance of some peripheral modules is limited or not available in this operating
condition.
Refer to the device datasheet to determine the supported features and the clock frequency of cores, modules,
and peripheral I/Os in OPP Low
Please refer below:
Is it true that the R5F has no L2 cache towards the DDR RAM?
The FAQ is being updated.
Please review the FAQ frequently for updates.
Regards,
Sreenivasa
Hi Board designers,
Refer below for information related to processor PLL
Errata reference
i2424 PLL: PLL Programming Sequence May Introduce PLL Instability
https://www.ti.com/lit/er/sprz487f/sprz487f.pdf
Do not use clk_pll_16fft_cal_option4() in SYSFW. Ensure to use updated PLL programming sequences in SDK v10.0 or later when performing any PLL configuration change
What you are saying is that if the register that customer refers to is changed, it is necessary to make it consistent with the settings of other related registers, therefore, DM provides a service to set the PLL, etc.?
Absolutely! And several aspects of the programming sequence were optimized in SDK10. There is now a usage note in the errata doc which refers to this
The registers associated with the calibration circuit when programmed in the wrong sequence, can lead to a lock loss error. Please refer to the function mentioned in the errata.
2. PLL0_HSDIV1 is used by I2C, please check the I2C Integration section in the TRM for more info
3. This information is in the errata description. The errata is induced because of an incorrect programming sequence when configuring the PLLs, which is present in older versions of SYSFW. To avoid the lock loss issue, please use SDK10, which has modified SYSFW and does not have the incorrect programming sequence
The reason for the error is simply a misconfiguration of the VCO frequency VCO max frequency is being violated, and thus PLL may lose lock or otherwise cause unpredictable behavior, especially at PVT corners
I found the SDK10.1 release notes describes here
can pick up the PLL updates on top of SDK9.2, so I will follow this to update the SYSFW first, and later update all SDK to 10.1
software-dl.ti.com/.../Release_Specific_Migration_Guide.html
PLL Programing Sequence Update To Avoid PLL Instability
In 10.00 SDK release, PLL programing sequence has been updated to follow the correct programing sequence to avoid PLL instability. The PLL programing sequence has been updated in following components of the SDK.
TIFS firmware (ti-linux firmware repo)
DM R5 firmware (ti-linux-firmware repo)
R5 SPL (u-boot repo)
SDK 10.0 has all the updated components by default.
e2e.ti.com/.../5777147
The same is applicable for AM243 as well and documented in the AM243 documentation.
software-dl.ti.com/.../SYSFW_PLL_UPDATE_GUIDE.html
e2e.ti.com/.../5603152
due to device errata i2424 (PLL instability problem), it is highly recommended to use SDK10.x.
e2e.ti.com/.../5486383
I assume you are using Linux on the A53 cores, and you are asking about detecting frequency fluctuations in the A53 cores specifically?
Please note that PLL instability was possible on earlier versions of the Linux SDK. SDK 10.0 is released with updated firmware that fixes the PLL instability. For more information, look here: software-dl.ti.com/.../Release_Specific_Migration_Guide.html
Clock Tolerance for PLL MAIN_PLL0_HSDIV4_CLKOUT
Could you please provide the clock tolerance specification for the MAIN_PLL0_HSDIV4_CLKOUT PLL that clocks the MCAN0 peripheral.
We determined the 6-sigma frequency error of the PLL output (80 MHz) that is sourcing the MCAN controller by measuring N-cycle jitter over a period of forty 80MHz clock cycles, which represents one bit time when operating at 2Mbps. The frequency error was calculated by applying the worst-case N-cycle jitter to the nominal period of forty clock cycles, or one bit time. The maximum frequency error of a single bit across the entire process, voltage, and temperature operating range (-40 to 125 junction) was 0.022%.
We also measured the frequency error over a period that represents 10 bits at 2Mbps, which is the resynchronization period for MCAN. The maximum frequency error of the resynchronization period across the entire process, voltage, and temperature range (-40 to 125 junction) was 0.003%.
We determined the 6-sigma frequency error of the PLL output (80 MHz) that is sourcing the MCAN controller by measuring N-cycle jitter over a period of ten 80MHz clock cycles, which represents one bit time when operating at 8Mbps. The frequency error was calculated by applying the worst-case N-cycle jitter to the nominal period of forty clock cycles, or one bit time. The maximum frequency error of a single bit across the entire process, voltage, and temperature operating range (-40 to 125 junction) was 0.064%.
We also measured the frequency error over a period that represents 10 bits at 8Mbps, which is the resynchronization period for MCAN. The maximum frequency error of the resynchronization period across the entire process, voltage, and temperature range (-40 to 125 junction) was 0.010%.
We did not measure jitter for the operating condition that represents 5Mbps, but the result would be somewhere between the 8Mbps and 2Mbps values.
Note: We do not have any plans to measure jitter for any other operating conditions.
(+) AM625: How to measure lpddr4 clock - Processors forum - Processors - TI E2E support forums
You might be able to find a via on the board that is associated with the CK signal that you can monitor.
Otherwise, you can output MAIN_PLL12_HSDIV0_CLKOUT out to the OBSCLK0 pin to observe the PLL frequency. This frequency will be 1/2 the memory clock (eg, 400MHz if the DDR_CK is 800MHz). See section 6.4.3 for information on how to setup the OBSCLK0 pin.
Can we perform Signal integrity validation check on the DDR clock probed on the vias without causing any loading effect due to the probe.? kindly let us know.
Yes, typically you would need to use high speed active FET probes
We do not support spread spectrum on any PLL. The SDK by default disables spread spectrum on all PLLs
(+) AM6442: DDR4 CLK Setting - Processors forum - Processors - TI E2E support forums
1. Yes, it will be a fixed value if you choose 800MHz memory clock operating frequency in the DDR register configuration tool. Other frequencies will have a different PLL configuration, but the PLL will always be half of the memory clock frequency
2. Yes
There is nothing that configures the DDR PHY PLL. This is inherent in the design.
Could you please help us to understand what the default values of clock in the clock tree.
What is the value of default clock in:
Based on these inputs, we assume the following as the default clock values:
Could you please confirm!
| Sl No | Clock Name | Value |
| 1 | HFOSC0_CLKOUT | 25 MHz |
| 2 | MAIN_SYSCLK0 | 500 MHz |
| 3 | MCU_SYCLK0 | 400 MHz |
| 4 | DEVICE_CLKOUT_32K | 32 KHz |
| 5 | MCU_PLL0_HSDIV3_CLKOUT | 800 MHz |
| 6 | MAIN_PLL0_HSDIV4_CLKOUT | 80 MHz |
| 7 | MAIN_PLL15_HSDIV0_CLKOUT | 400 MHz |
| 8 | CLK_12M_RC | 12.5 MHz |
The values are correct.
Recommended PLL setting approach
The DM operations will be performed by the DM core.
Typically, these PLL settings are configured by DM core and change of PLL effects to SOC operations.
So, mostly, we do not encourage customers to change them
we plan on putting the following note in the TRMs
Most of the PLLs are required to operate at a fixed preset frequency.
I don't see a maximum frequency specified in the TRM or above in this thread. Is the implications that we shouldn't run PLL1 faster than the default 1920MHz? Per the TRM other PLLs run in the ~2.5GHz range, does this not apply to PLL1?
The maximum Frequency for the PLL is 3.2GHz.
Regards,
Sreenivasa
Hi Board designers,
Refer inputs related to DMA and PDMA
We need to enable DMA transfers for MCSPI and MCAN.
Q1. Is the following understanding correct?
Q2. Do PDMA1 and PDMA2 support DMA transfers for MCAN?
The MCSPI and MCAN peripherals support both TX and RX DMA channels.
However, the DMA channels for MCAN and MCSPI are statically mapped to either PDMA0, PDMA1, or PDMA2, depending on the SoC architecture.
This means that the peripheral-to-DMA connections are fixed in hardware and cannot be reassigned from one PDMA instance to another.
We need to continuously perform high-speed, high-volume communication (Clock: 6 MHz, Data Size: 2 KB) in SPI Slave mode within the MCU domain.
However, when we set the MCSPI Operating Mode to "DMA Mode" in the SysConfig for the MCU domain, we receive the message: "DMA is not supported in MCU Domain."
We were planning to use DMA for this purpose—does this mean that DMA is actually not available in the MCU domain?
If DMA is indeed not supported, could you kindly suggest any alternative solutions to achieve our communication requirements?
The MCU core does not support PDMA, so the MCU domain MCSPI cannot be used with DMA.
If the customer wants to use DMA with MCSPI from the MCU core, they can access the MAIN domain MCSPI, which supports DMA .
This allows high-speed data transfer without CPU overhead.
However, if the customer prefers to use the MCU domain MCSPI, they must operate it in interrupt mode since DMA is not supported.
Performance Considerations:
• SPI Clock: 6 MHz
• Payload Size: 2 KB (2048 bytes)
• Theoretical Transfer/Read Time:
2048 * 8 / 6M = 2.73msec
• Interrupt Configuration:
The MCSPI RX FIFO can be configured to trigger an interrupt at 32 bytes.
• Time to receive 32 bytes:
32*8/6M = 42.67usec
Based on this analysis, the customer can choose between:
1. MCU domain MCSPI in interrupt mode:
• Suitable if CPU has enough headroom to handle interrupts every 42.67 µs.
2. MAIN domain MCSPI with DMA:
• Recommended for minimal CPU involvement and better performance.
Please evaluate these options and select based on your application’s real-time constraints and system architecture.
Regards,
Sreenivasa
Hi Board designers,
Refer inputs related to internal clock error detection
I added the inputs from out reset expert:
The expectation is that the fault is routed to the ESM, and some external circuit would generate a power cycle or cold reset so the system can recover. I think this is the only way the clock loss detection circuit would reset the detection. Also, MCU_PORz is the only way CLKLOSS_SWITCH_EN bit gets reset. So a warm reset will not help here, and that is why they observe the 12MHz_RC still clocking the processor after a warm reset
The RC clock backup is not available immediately after PORz because of the default value of CLKLOSS_SWITCH_EN. There is some setup that needs to happen anyway, in that the error needs to be routed to the ESM to trigger the ERROR signal, so that an external can do something about it (power cycle the device, for example). When all that is setup, the RC clock will clock the device after a fault, but it is only intended to keep the ESM alive to generate the appropriate ERROR signal. It is not expected that the device will operate fully.
On a cold reset, if the 25MHz is not available, the device will not boot. Even if the clock loss detection circuitry works at that point, the CLKLOSS_SWITCH_EN defaults to 0 as mentioned previously, so the mux will never switch to the RC clock. Even if it would be able to switch, the ROM does not support booting with that input frequency.
Regards,
Sreenivasa
Hi Board designers,
Additional inputs on processor supplies:
Connection recommendations for processor supply rails when peripherals or IOs are not used and connection of RSVD pins
I want to know what’s the lowest current consumption in MCU LPM (MCU ONLY MODE) , which should include PMIC?
The MCU-only low power mode benchmark measured with our EVM can be found here: https://www.ti.com/lit/an/spradg1/spradg1.pdf.
For power optimizations: customers can reduce the clock speed of the MCU M4F PLL and also configure the PMIC to operate in auto-PFM. PMIC operates in auto-PFM when the MODE/STBY pin is pulled low. AM620-Q1: Power Consumption Optimization For MCU Only mode (or deep sleep mode) - Processors forum - Processors - TI E2E support forums
Regards,
Sreenivasa
HI Board designers,
Inputs related to delay between supply rails for processor power-up sequence
Input 1
The VDDS_DDR and VDDS_DDR_C power rails are expected to be powered from the same power source. This waveform shows a grey transition region that begins with the first rising edge and ends with the second rising edge. The supply that powers VDDS_DDR and VDDS_DDR_C can change anywhere in the grey transition region. So it is okay for the the 0.85V supply to ramp before the 1.2V supply.
Note: We insert multiple transitions within the grey transition region of some waveforms when they represent a transition region for power rails which may receive power from multiple sources. Multiple transitions within the region is used to indicate these power rails can ramp anywhere within the transition region and they do not have any dependency on the other power rails associated with the waveform. Transition regions like the one used for VDDS_DDR and VDDS_DDR_C, indicate all power rails associated with the waveform are powered from a common source and are expected to ramp at the same time anywhere within the transition region.
The shaded region of the waveform represents a range of time where a supply may ramp up/down relative to other supply rails. The hatch marks within a shaded region is used to represent multiple power rails just in case all power rails represented by a waveform are not powered from the same source. For example, there may be a reason to power some 1.8V power rails form one source while other 1.8V rails are powered from another source.
I will be adding legends to this section of the datasheet to describe these two types of transition regions.
Input 2
There is only one firm requirement for AM64x power-down. See note 5 associated with the power-down sequence.
The potential applied to VDDR_CORE must never be greater than the potential applied to VDD_CORE + 0.18V during power-up or power-down. This requires VDD_CORE to ramp up before and ramp down after VDDR_CORE when VDD_CORE is operating at 0.75V. VDD_CORE does not have any ramp requirements beyond the one defined for VDDR_CORE. 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.
Input 3
Can we share the requirements of timing between the different voltage supply waveforms rising on power-up and falling on power-down. For example, how long after Waveform A rises must Waveform B wait before rising?
There are no specific timing requirements for these sequencies. The sequence defined in the datasheet is only required to prevent voltage potential differences.
in Figure Power-Up Sequencing of the Datasheet, is there requirements for the time interval of each voltage?
* Spacing of vertically drawn dashed lines
No. No specific time is required between the groups as long as one has ramped before the next begins.
Customer follow SK-AM62B-P1 design and use same PMIC and found MCU_OSC0 clock start up timing is not matching the sequence we describe in Data Sheet.
This is confirmed on both customer board and TI EVM.
MCU_OSC0 is supposed to be clocking after VDD_Core rising but the waveform measurement shows it is ahead VDD_CORE.
Customer would like to get the explanation from TI for this.
Could team check this or we need to revise data sheet?
The datasheet shows it not starting until after the core voltage because there are some cases where the oscillator may not start until VDD_CORE is valid. In most cases it will start as early as VDDS_OSC0, but this may not always be the case.
This diagram in the datasheet is showing the maximum start-up time, which must include the case where the delay is based on VDD_CORE being valid.
AM625: AM6254 power up sequence question
Will the external circuit(e.g SPI slave side) influence the AM6254 power up sequence? i mean if the SPI or other communication interface(slave side) power up first, will it introduce some current into the AM62 and mess up the AM62 power up sequence?
Many of the AM62x pins are not fail-safe and they should not have any potential applied until their respective power rail has ramped to a valid level. For more information refer to the Absolute Maximum Ratings and Recommended Operating Conditions tables in the datasheet.
AM6442: Powering AM6442BSFFHAALV with TPS6522430RAHRQ1
The processor sequencing requirements can be found in the datasheet under "Power Supply Sequencing".
Power Supply Sequencing I can only find the order of the rails.
However, the delays between the different power supplies are not specified in the datasheet.
The only delay mentioned is the one between “all supplies valid” and the MCU_PORs (9.5ms).
Does this mean that the delays between the power supplies themselves don’t matter, and only the sequence is relevant?
We do not specify the delay between rails. Instead, we have slew rate requirements and sequence order. A supply group must fully ramp to the targeted output voltage with the required slew rate before the next one in sequence start ramping up.
AM625-Q1: Power-down sequence
To which level do we have to discharge the voltages until a next power-up cycle is allowed?
What can happen with the SoC, if we don't follow the proper power-down sequence?
The power-down sequence diagram will be updated in the next revision of the datasheet. The update has already been applied to the AM62Ax and AM62Px datasheets released on ti.com, so you can reference one of these updated power-down diagrams until the AM62x datasheet is updated later this year. We are basically allowing the IO supply to delay their turn-off until the last core supply is turned off. The previous power-down diagram showed the IO supplies being turned off by the time VDD_CORE was turned off. This is still the preferred sequence, if possible, to help prevent the IOs from doing unpredictable things during power-down since logic in the core domain controls the IO functions. However, we found this was difficult to implement and decided the internal circuits that force the IOs to a known state until VDD_CORE ramps-up should perform a similar task during power down when VDD_CORE is lost before the IO supply. We do not want customers leaving IO supplies powered for long periods of time after the VDD_CORE is turned off, so we decided to extend each IO supply turn off until the last core rail is turned off as way to limit the time IO are turned on after VDD_CORE is turned off.
It appears you are showing an uncontrolled power-down sequence where all supplies are turned off at the same time, which is consistent with the new power-down diagram as long as you ensure the potential applied to VDDR_CORE is never greater than the potential applied to VDD_CORE + 0.18V during power-up or power-down. This is the only absolute voltage difference that must be managed during power-down.
The following note will also be added to the next revision of the AM62x datasheet. This note has already been added to the AM62Ax and AM62Px datasheets.
All power rails must be turned off and decay below 300mV before initiating a new power-up sequence anytime a power rail drops below the minimum value defined in Recommended Operating Conditions. The only exception is when entering/exiting Partial IO low power mode with VDDSHV_CANUART and VDD_CANUART sourced from an always on power source. For this use case the VDDSHV_CANUART and VDD_CANUART power rails are allowed to remain on.
One issue is, that we can't guarantee the decay down to 300mV. As U18S takes up to 4 sec for decay, there is a high probability to start a new power-up cycle before it reaches 300mV. Can you assess, what can happen in this case? Do you expect any malfunction or damage due to this improper power cycle?
I'm not aware of any way this can damage the AM62x device. There could be use cases where this causes a functional issue in your system.
I also do not anticipate an issue with the AM62x device because the power-on reset input should reset every circuit in the device to the same known state every time reset is asserted. Therefore, the AM62x device should not retain any previous state held by the power not fully decaying. However, this operating condition was not expected and not validated.
You could encounter system level issues, where other components in your system will not function if you do not allow all supplies to decay. For example: Not allowing the supplies to decay may be a problem for an SD Card connected to AM62x since the SD Card is only reset when you cycle its power, and its supply voltage drops below a specific value defined in the SDIO standard. This is required because SD Cards do not have a reset pin, so they have an internal reset circuit that generates a reset by monitoring the SD Card supply voltage. This can be a problem if the SD Card was previously told to switch to 1.8V IO signaling and you short cycle the power supply such that the AM62x MMCSD host is reset and begins communicating with the SD Card using its default 3.3V IO signaling when the SD Card is still configured to 1.8V signaling because it was not reset.
We recommend customers design their system to decay below 300mv to minimize any risk of these type of problems.
Regards,
Sreenivasa
