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 likely a misconfiguration of the VCO and thus PLL may lose lock or otherwise cause unpredictable behavior, especially at PVT corners

 (+) AM6422: What's the performance of PLL module - Processors forum - Processors - TI E2E support forums

I found the SDK10.1 release notes describes here

https://software-dl.ti.com/processor-sdk-linux-rt/esd/AM64X/10_01_10_04/exports/docs/devices/AM64X/linux/Release_Specific_Migration_Guide.html#:~:text=Linux%20SDK%2009.02%20was%20the%20last%20SDK%20release%20with%20LTS%20Kernel%20version%206.1%20and%20u%2Dboot%20version%202024.x.%20To%20pick%20up%20the%20PLL%20updates%20on%20top%20of%20this%20SDK%2C%20pick%20the%20components%20listed%20below%20when%20building%20the%20u%2Dboot%20binaries.

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

e2e.ti.com/.../5936131
e2e.ti.com/.../5936134

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.

There are some system level considerations that can contribute to clock error such as crystal selection, power supply noise, etc. Internally the PLL can produce some small level of jitter as well. The topic of clock accuracy for CAN is complicated as part of the protocol provisions for resynchronization and there are some concepts of short and long term jitter over bit times. 

(+) 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

AM623: Does AM623x support DDR CLOCK Spread Spectrum? - Processors forum - Processors - TI E2E support forums

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.

AM62P: Reg Default Clock Tree Information

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:

• HFOSC0_CLKOUT
• MCU_SYSCLK0
• MCU_PLL0_HSDIV3_CLKOUT and other MCU PLL Clocks
• MAIN_SYSCLK0
• DEVICE_CLKOUT_32K
• MAIN_PLL0_HSDIV4_CLKOUT and other main PLL clocks

Based on these inputs, we assume the following as the default clock values:

Could you please confirm!

 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

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1464980/am62a7-max-pll-frequency/5621848 

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, 

E2Es for reference on COREs

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1204069/faq-sitara-multicore-development-and-documentation 

Sitara multicore development and documentation

(+) [FAQ] [AM6XX]: How to check if device type is HS-SE, HS-FS or GP? - Processors forum - Processors - TI E2E support forums

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1228618/faq-am6xx-how-to-check-if-device-type-is-hs-se-hs-fs-or-gp 

(+) AM625-Q1: Display sharing in AM625-Q1 - Processors forum - Processors - TI E2E support forums

(+) [FAQ] AM64X/ AM62X : How to Reset the SOC when WDT timer expires in AM64X and AM62X? - Processors forum - Processors - TI E2E support forums

Current AM64X and AM62X devices support DWWD (Digital Windowed Watch Dog). 

The DWWD opens a configurable time window in which the watchdog must be serviced. Any attempt to service the watchdog outside this time window, or a failure to service the watchdog in this time window, will cause the watchdog to generate an NMI for the self-CPU.

In this situation, who should reset the crashed core? Typically, the expectation is to self-reset the SOC when WDT has expired, but this is currently not supported by MCU+ SDK code running on AM64X and AM62X devices. (Note, Linux will reset the processor after a Linux watchdog timer generates an NMI)

(+) TDA4VM: J7200] Could you explain Watchdog sequence ? - Processors forum - Processors - TI E2E support forums

I am assuming you are asking about SoC RTI watchdog reset.

There are 3 parts to it:

1. RTI Module which has the timer expiry.
2. SOC ESM - This is the error signaling module that needs to catch the watchdog RTI timer expiry.
3. ESM PMIC which is PMIC part to trigger a SoC reset upon ESM event.

1 --> is taken care by the RTI watchdog driver: https://github.com/torvalds/linux/blob/master/drivers/watchdog/rti_wdt.c

2 --> Is done as part of R5 SPL repo: https://github.com/u-boot/u-boot/blob/master/drivers/misc/k3_esm.c

3 --> Is done as part of R5 SPL in U-Boot repo: https://github.com/u-boot/u-boot/blob/master/drivers/misc/esm_pmic.c

This is functional in 9.2 SDK.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1405983/tmds64evm-about-the-gpmc-clock/5521424#5521424

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1532626/am2432-r5f-cache-configuration/5894855#5894855

I am searching for the cache configuration of AM243x regarding R5F cores, MSRAM, and DDR RAM.

In the TRM (spruim2h), 64kB cache is mentioned for the R5F subsystem (32kB instruction + 32kB data). L2 Cache is only mentioned for the A53 subsystem.

Is it true that the R5F has no L2 cache towards the DDR RAM?
This is correct.

(+) AM625: Is there a shared memory block between the A53 and M4 cores? - Processors forum - Processors - TI E2E support forums

 am working on a custom design based around the AM62x. One part of the design will be doing real-time sampling with the PRU core and sharing the resulting data with the A53 core(s); this part is already well-documented and understood.

The next part of the design will be doing slower real-time sampling with the M4 core and sharing the resulting data with the A53 core(s). For this part, I have not been able to find that there is any common memory buffer that can be used to share data between the M4 and A53 cores. The idea would be to allocate a shared memory region, which the M4 core would write data into, and then the A53 could read that data out of.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1523518/am6442-l1-cache-use-for-memory-storage/5858660#5858660

The Cache is specific to the R5F core and TCM memory is specific to SOC.

The TCM memory is memory maped to the SOC. So, all cores like the R5F, A53 core and M4F core can access this memory.

So, the R5F core or A53 core can't access the cache memory as storage because this cache memory is not memory mapped to the SOC.

(+) AM625: MTBF/FIT estimates needed - Processors forum - Processors - TI E2E support forums

We’re quoting customers 10 FIT target at 105C/100kPOH based on intrinsic design.

Successful UART boot 

 RE: AM620-Q1: Asymmetric Multiprocessing 

Below is the data we get while booting from uart 02000000011a0000616d3632610000000000000048534653000800000008000002a6000000000000cb39ee39c52d0469806636ff350520fcf7065cbec5cdddfea08863506c2be9f2242ff3207f919c2edcff407261f0908459139f3c153770f3024c4eae43a71151ad0bc40b0000000000000000000000000000000C

(25) AM6442: EtherCAT versions - Processors forum - Processors - TI E2E support forums

One PRU-ICSSG has 2 Ethernet ports, connecting over MII (or RGMII) to a PHY, implementing one EtherCAT Slave Controller (ESC). The AM64x devices have 2 PRU-ICSSG's that can be connected to 4 PHY's. You can run one PRU-ICSSG based ESC connected to two PHY's and the second PRU-ICSSG remains for other use. Or you could run 2 ESC stacks in 2 separate EtherCAT line topologies using 4 PHY's. Did this answer the question?

(25) AM6421: AM6421 system: No firmware, VDD_CORE，VDDSHV_MCU and VDDSHV0-3 short - Processors forum - Processors - TI E2E support forums

You can get unpredictable results when measuring continuity of a power rail with a multimeter because the potential applied to the device by the multimeter can bias circuits in unpredictable ways. For example, the multimeter may trigger internal ESD protection circuits attached to the power rails.  If this happens the ESD circuits may think the potential applied by the multimeter is an ESD event, where the ESD circuits shunts current to ground.

The results of a continuity test can be misleading unless you power all of the power rails in the sequenced defined in the Power Supply Sequencing section of the datasheet with a ramp rate that is less than the max slew rate defined in the Power Supply Slew Rate Requirements section in the datasheet, and the potential applied never exceeds the voltage limits defined in the Absolute Maximum Ratings table.

Are you trying to measure continuity of the device power rails after it is installed on a PCB along with other components, or before the device is installed on a PCB? The multimeter may be measuring continuity through other components on the PCB if you are trying to make the measurement on an PCB assembly.

Have you tried applying power to the device to see if there is a problem?

(25) AM6412: QSPI timing specification - Processors forum - Processors - TI E2E support forums

ROM code uses tap mode @ 50 MHz and not PHY mode.

In ROM, the DEV_DELAY_REG is set to 0x0.

What is actually used for tap mode is the RD_DATA_CAPTURE_REG DELAY_FLD bit[4:1]. For which we (ROM) scan all possible value to find the optimum setting.

So for ROM only DEV_DELAY_REG does not matter.

After boot, in their higher level s/w, if they would need/want to enable PHY mode to increase throughput then they would need to set these I imagined.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1545920/am620-q1-asymmetric-multiprocessing/5948312

The AM62x is capable of doing processing on the Linux A53 cores, RTOS or bare metal on the M4F core, and bare metal code on the PRU cores, and then passing data between all the cores. However, I am not an audio specialist, so I am not sure if we have evaluated M4F performance in audio usecases or not.

If you use a hypervisor, you can run Linux on a part of the A53 cluster, and RTOS on another part of the A53 cluster.

In general, I would not suggest dividing up the A53 cluster without using a hypervisor, since management of shared resources like the cache is a lot more difficult without a hypervisor coordinating the resource usage.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1542957/am625-cpsw-support-on-m4-core-from-am625/5934920 

CPSW support on M4 core from AM625

We currently don't support Networking on M-core for AM62x. We only support Networking on A53 core, with Linux and RTOS platforms. AM26X and AM62X are of different series of products and differ in the offerings. But even AM26X doesn't support Networking drivers on M core.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1541622/am62p-how-do-the-a53-cores-access-mcu_i2c-mcu_spi 

How do the A53 cores access MCU_I2C/MCU_SPI

MAIN" and "MCU" refer to power domains.

In general, the Main domain cores can reach across into the MCU domain to access peripherals, and the MCU domain cores can reach across to Main domain peripherals.

The exception to this is if you have firewalled off the MCU domain core for something like a safety / security usecase. If there is a firewall between the domains, then neither core can reach across the firewall.

Interrupt connectivity matters 

A lot of peripheral drivers assume an interrupt connection. This is more of an issue on AM62x than AM62Px (where on AM62x, some peripherals do NOT have interrupt connectivity across the MAIN / MCU domain). For all AM62 family processors, I suggest referring to the Technical Reference Manual (TRM) section Interrupts > Interrupt Connections Summary for an overview of which peripherals have interrupt connections to the GIC (which feeds the A53 cluster)

Don't forget to allocate your peripherals! 

This is the most common issue I see customers run into, when multiple cores try to request the same peripheral, and then the second request fails. You can find more information about peripheral allocation in the AM62Px academy here:

Multicore > Peripherals:
https://dev.ti.com/tirex/explore/node?node=A__AcGdexDmDxV8k7XSDZd.4w__AM62P-ACADEMY__fp5YxRM__LATEST

Multicore > Application Development on Remote Cores:
https://dev.ti.com/tirex/explore/node?node=A__AW0cwnZVbDqRS5d4OiCx6A__AM62P-ACADEMY__fp5YxRM__LATEST

Regards,

Sreenivasa

Hi Board designers, 

Refer inputs related to internal clock error detection

(47) [FAQ] AM6422: How to Switch Back to External Clock After Clock Loss Detection - Processors forum - Processors - TI E2E support forums

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, 

Additional inputs related to security

The ROM itself loads the TIFS. The R5 SBL image is a combined image which contains the actual SBL Stage1, TIFS, and Board Configuration binaries.

After the SBL Stage1, the bootflow is described in the following guide:

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62PX/11_01_00_16/exports/docs/api_guide_am62px/SBL_BOOTING_LINUX_EMMC.html#autotoc_md229

(+) AM623: Secure Boot Flow, KEY security, BMPK strategy - Processors forum - Processors - TI E2E support forums

Please refer to the FAQs on the topic.
[FAQ] SYSFW API on key revoke in OPTEE on AM62x 
[FAQ] AM6442/AM243: How to use the TISCI APIs (READ_KEYCNT_KEYREV & WRITE_KEYREV) to activate the backup key set 

This is an early e2e
RE: AM623: Does AM62x support revocable Root of Trust (RoT) or Certificate Authority keys 

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1544838/am623-please-help-to-provide-safety-features-documents-for-am623/5949208 

Yes, all AM62x series (AM625, AM625-Q1, AM623, AM620-Q1) support FuSa. Please see the "Functional Safety" section in the respective datasheets:
Eg: https://www.ti.com/lit/ds/symlink/am623.pdf 

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1544858/faq-am623-functional-safety-certification-document-for-am62x-am644x 

The safety manual and FMEDA documentation for AM62x device can be requested at the below link:
https://www.ti.com/secureresources/AM62Q-17X17-RESTRICTED-DOCS-SAFETY 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1544858/am623-functional-safety-certification-document

The safety certificate from TUV is available at https://www.ti.com/product/AM625#tech-docs 

https://www.ti.com/lit/fs/sffs744a/sffs744a.pdf 

www.ti.com/.../sffsb07.pdf

Here is the link of the OTP Keywriter tutorial as well:
https://dev.ti.com/tirex/explore/node?node=A__AagJ-8QGXM582KzTgxFZbA__AM62-ACADEMY__uiYMDcq__LATEST

(+) AM2434: Hardware integrity up to SIL Standard - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

We have previously had customers use two SIL2 AM243 SoCs together to achieve a SIL3 safety level. Would that be a feasible solution for you?

Is there any reference design available?

Link : www.ti.com/.../AM64X-RESTRICTED-DOCS-SAFETY

If we use two SIL2 AM243 SoCs in our design, do we still need to obtain a separate SIL3 certification?

Regards,

Sreenivasa

Hi Board designers, 

Additional inputs related to RSVD pins.

I would like to know the behavior of the AM62A when this reserv pin is shorted to the power supply or GND. Therefore, I would like to know the electrical behavior including the rated voltage.

Please refer inputs i received from the expert:

The customer should never purposely connect anything to these pins or allow them to be connected anything by accident.  There characteristics of these pins are not defined because the customer should never connect anything to them.  The device may not work as expected and may be damaged if they connected to power or ground.  The customer must ensure this never happens.

We are currently checking our products from the perspective of functional safety.

It is necessary to know what mode it will fall into when a failure occurs, and the above information is necessary for that.

I understand that it is a "Reserve pin", but could you please answer my question?

Please refer below inputs i received from the device expert and design team.

We expect customers to do whatever is necessary to ensure the reserved pins never get connected to anything.  We expect customers to do whatever is necessary to ensure the reserved pins never get connected to anything.  We did not validate the device operation for any other condition.  Therefore, so we are not able to say what will happen if they allow any of the reserved pins to connect to other pins or signals.
The SOC may not work properly. Just like if a power pin were shorted to ground. 
They need to have some mechanism like a challenge-response watchdog external to the SOC to Protect against this. 

Please refer inputs i received from the expert:

The safety concepts we show always have a separate monitor device that can cause the system to be in a safe state

Regardless of what happens to the SOC.   They need to treat issues with these reserved pins like shorting to a supply rail

As possibly causing the SOC to be completely offline / possibly damaged / and possibly shorting out the power rails connected

To the SOC.

The monitor needs to be independent enough to cause the safe state entry if any of those things happen.

We cannot give more detail or guarantee behavior on reserved pins past what is documented in the datasheet.  

(+) AM625: RSVD pins - Tristated or have a potential? - Processors - INTERNAL forum - Processors - INTERNAL - TI E2E support forums

AM625: RSVD pins - Tristated or have a potential?

The reserved pins are for TI use only.  They are not traditional IO pins and there are no plans to disclose their function. The customer needs to follow the datasheet recommendations, where it says to leave these pins unconnected. Leave unconnected means do not connect any PCB signal trace to these pins.

The device could be damaged if these pins short to an adjacent ball, which is the same for any ball on the package.

There is no action the customer can take for these pins other than do not connect any PCB trace.

There are lots of pins on the AM62x device that would not tolerate a short to an adjacent pin. So they need to ensure this never happens.

Regards,

Sreenivasa

Hi Board designers, 

Additional inputs related to GPIO usage

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1398198/faq-am62x-how-to-allocate-use-gpios-from-different-device-domains 

I want to use MCU GPIO from A53/Linux or Main Domain GPIO from M4/MCU. How can I allocate these GPIOs and use them?

(+) AM623: Disabling MCU (M4) to Use MCU_UART0 Port from Main Domain — Impact and Considerations - Processors forum - Processors - TI E2E support forums

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1551569/am623-disabling-mcu-m4-to-use-mcu_uart0-port-from-main-domain-impact-and-considerations/5972414

Peripheral allocation

Each peripheral on the AM62x was designed to have a single SW owner. So Linux can use a UART instance, or the M4F can use a UART instance, but both processors cannot use the same UART instance. For more information about peripheral allocation, refer to the AM62x academy:
Multicore > peripherals > how to allocate peripherals
https://dev.ti.com/tirex/explore/node?node=A__Ab9v-ikRLJrpmmd7B-xvUw__AM62-ACADEMY__uiYMDcq__LATEST

Can a processor core in one power domain control a peripheral in another power domain? 

It depends.

1) Has the MCU domain been isolated for safety or another usecase?

If there is a firewall between the MAIN and MCU domains, then a core cannot reach across the firewall to control a peripheral on the other side.

2) Is there interrupt connectivity between the peripheral and the processor core?

For a summary of interrupt connectivity, refer to the AM62x Technical Reference Manual (TRM) section 
Interrupts > Interrupt Architecture > Interrupt Connections Summary

You can see that there is interrupt connectivity between the GIC (That's for the A53 cores) and UART:MCU domain. So you should be good to go.

Will the MCU domain M4F firmware run properly if the MCU_UART is disabled in the M4F's SysConfig settings? 

The MCU_UART is not a requirement for the firmware to run. You would need to talk with your RTOS team to understand what code they are programming for the M4F (if you are programming the M4F in your design).

Some questions that you might have to consider include "How will we debug the M4F firmware during development". For more resources on how to do stuff like that, please refer to the AM62x academy:
Multicore > Application Development on Remote Cores
https://dev.ti.com/tirex/explore/node?node=A__ATWfO3c7FkPk06K9x1nvpA__AM62-ACADEMY__uiYMDcq__LATEST

(+) PROCESSOR-SDK-AM62X: About AM62x M4F Core Program Optimization - Processors forum - Processors - TI E2E support forums

he device is not architected to be optimized to run out of DDR from M4F.  M4F is meant  to run out of local memory as it does not have a cache like the R5F or A53 cores do.  Please refer to: 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1187962/faq-sk-am62-how-to-execute-code-from-external-memory-using-m4f-core 

Regards,

Sreenivasa

Hi Board designers,

Refer below inputs related to package delay.

 the package pin delays can be found in the AM62P DDR layout guidelines , section 4

https://www.ti.com/lit/pdf/sprad66

Aside from DDR delays listed in the PDF file, there should be package delays for all other CPU High speed interface balls such as SD/MMC,DSI,LVDS,RGMII etc.

Typically there is a internal package delay file provided (as was the case for AM62x). These delays are required since they should be taken into account in length matching. There are no internal package delays included in the EVK reference .brd layout file.

we don’t supply that to customers.  Why do they need it?  I think for most peripheral frequencies, the package delay would be a small fraction of the rest of the board trace.

Following the DDR design guide should be Ok. You could also reference the SK and the EVM.

Please refer below inputs from the expert:

we don’t typically share package delay information for the entire device.  The customer should be consulting the High Speed Layout Guidelines app note https://www.ti.com/lit/pdf/spraar7 which has layout information for some of the non-DDR interfaces. 

 For AM64x DDR specifically, the PHY has a per bit skew feature which will compensate for length mismatches during training.  This will help accommodate package length mismatches.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1554534/tda4aen-q1-pin-package-delay-needed-for-lpddr/5982747 

Yes - pin delay (package) should be taken into consideration when layout of a PCB design.  Yes - we try to account for these delays when designing our EVMs.  Sometimes the EVM and package are designed at same time, and package is not final when EVM is completed.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1421855/am67a-soc-package-delay/5474846 

Do you also have the RLC-data for the DDR pins? It would improve the Sigrity simulation of these nets.

Yes, if you search for the word "matrix" in the ibis model you'll find the following:

Model Data]
|
| The resistance matrix for this package has no coupling
|
[Resistance Matrix] Banded_matrix
[Bandwidth] 0
[Row] H17
0.032209

<snip>

|
| The inductance matrix has sparse coupling
|
[Inductance Matrix] Sparse_matrix
[Row] H17
H17 4.35728e-10
G19 1.09632e-11

<snip>

|
| The capacitance matrix has sparse coupling
|
[Capacitance Matrix] Sparse_matrix
[Row] H17
H17 7.79462e-13

AM625-Q1: Regarding PCB Pattern, should customer consider the pin delay in SoC for eMMC / QSPI / USB for pattern layout of PCB?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1532202/am625-q1-regarding-pcb-pattern-should-customer-consider-the-pin-delay-in-soc-for-emmc-qspi-usb-for-pattern-layout-of-pcb

Should customer consider the pin delay in SoC for eMMC / QSPI / USB for pattern layout of PCB?

For the propagation delay, the delay here is only for the peripheral traces on the board. There is no need to include any package level propagation delay.

The below E2E could help in case you have similar query for DDRSS.

(+) AM623: AM62x package internal DDR4 pin delay - Processors forum - Processors - TI E2E support forums

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1445913/tda4vm-pin-package-delay-for-csi-pins

No package delay information is available for CSI2.  Customers can assume they are matched on package.

e2e.ti.com/.../am62a7-q1-ddr-package-pin-delay

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.

(+) [FAQ] AM625: Long Term Effects of Simultaneously Power-Down Sequencing of all Voltage Rails - Processors forum - Processors - TI E2E support forums

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 - Processors forum - Processors - TI E2E support forums

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

Hi Board designers,

Inputs related for A53 revision.

6.1 Arm Cortex-A53 Subsystem (A53SS)

AM62P

root@am62pxx-evm:~# cat /proc/cpuinfo

processor : 0

BogoMIPS : 400.00

Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

CPU implementer : 0x41

CPU architecture: 8

CPU variant : 0x0

CPU part : 0xd03

CPU revision : 4

processor : 1

BogoMIPS : 400.00

Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

CPU implementer : 0x41

CPU architecture: 8

CPU variant : 0x0

CPU part : 0xd03

CPU revision : 4

processor : 2

BogoMIPS : 400.00

Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

CPU implementer : 0x41

CPU architecture: 8

CPU variant : 0x0

CPU part : 0xd03

CPU revision : 4

processor : 3

BogoMIPS : 400.00

Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

CPU implementer : 0x41

CPU architecture: 8

CPU variant : 0x0

CPU part : 0xd03

CPU revision : 4

root@am62pxx-evm:~#

root@am62pxx-evm:~# cat /proc/c

cgroups cmdline config.gz consoles cpuinfo crypto

root@am62pxx-evm:~# cat /proc/cpuinfo ^C

root@am62pxx-evm:~# ^C

root@am62pxx-evm:~# ^C

root@am62pxx-evm:~# k3conf read 0x730010D00

|------------------------------------------------------------------------------------------------|

| VERSION INFO |

|------------------------------------------------------------------------------------------------|

| K3CONF | (version 0.3-nogit built Wed Sep 17 13:14:15 UTC 2025) |

| SoC | AM62Px SR1.1 |

| SoC identifiers | [0x6a5db5ae] 0x352ed Func-Safe Secure 'V' Grade -40 C to 125 C AMH Package |

| SYSFW | ABI: 4.0 (firmware version 0x000b '11.1.5--v11.01.05d (Fancy Rat))') |

| DM ABI Info | 3.0 |

| DM F/w rev | 11.1.2 |

| DM Component rev | RM/PM HAL:'v11.01.02' SCI_SERV:'MSDK.11.01.01.04-dirty' |

| F/w Capabilities | 0x1f7: GEN DEEP_SLP MCU_ONLY PART_IO DM_MGD_LPM IO+DDR_RET IO_ISO DM-SPLT |

|------------------------------------------------------------------------------------------------|

Value at addr 0x730010d00 = 0x410fd034

Acknowledgement: Thank to Vignesh Raghvendra

AM64x

A53_0 - 0x00000000410FD034
A53_1 - 0x00000000410FD034

Acknowledgement: Thank to Tushar Thakar

Regards,

Sreenivasa

Hi Board Designers, 

Inputs related to EPWM and ECAP

What is the minimum/maximum frequency and highest resolution of main domain EPWM in AM6442?

It seems EHRPWM is not supported on this chip, is there any plan to be integrated?

The clock (MAIN_SYSCLK0) feeding the EPWM peripherals is 250MHz.

There is a pre-scaler in each EPWM module that can divide the input clock by 2^n , where n= 0 to 7 (See register EPWM_TBCTL).

There is a 16-bit counter used in each EPWM module. 

EHRPWM will not be supported on this device.

30 Hz clock generation
First, I would assume that MAIN_SYSCLK0 is 250 MHz, but please check your PLL configuration.

This clock enters the PWM prescaler which is controlled by the HSPCLKDIV and CLKDIV of the TBCTL register (figure 12-323).

Section 14.8.5.3.1.1 of the TRM describes these fields. Unfortunately, the AM62 TRM is incorrect there for some reason. One may find the correct description of these 2 fields in other TRMs such as the AM64 TRM (link www.ti.com/.../SPRUIM2) in table 12-4349. The TBCLK prescaled clock is defined as follows:

TBCLK = SYSCLKOUT / (HSPCLKDIV × CLKDIV)

with CLKDIV being:
0h: /1 (default on reset)
1h: /2
2h: /4
3h: /8
4h: /16
5h: /32
6h: /64
7h: /128

and HSPCLKDIV being:
0h: /1
1h: /2 (default on reset)
2h: /4
3h: /6
4h: /8
5h: /10
6h: /12
7h: /14

So, the slowest TBCLK that you may configure is 250 ÷ 128 ÷ 14 ≈  ~140 kHz, a period of ~7.15 us.

Then, the PWM counter (TBCNT) is a 16-bit counter, giving you the ability to divide the 140 kHz clock by up to 2^16, which gives a frequency of ≈ ~2 Hz if TBCLK = 140 kHz.
In conclusion, you may generate a frequency of 30 Hz. You won't even have to configure the highest prescaling ratio for TBCLK. The benefit of a faster TBCLK is that it gives you a better granularity on the duration of your PWM clock, thus achieving a better precision for your 30 Hz.

Thanks to your support we have been able to produce the 30Hz.

What are the drifts of RTC and GTC timers in AM625SIP? 

The RTC has an adjustment or calibration feature that allows software to compare the RTC clock time to a on-line standard clock occasionally and apply an adjustment that get applied periodically to minimize the long-term error introduced by the clock source. It has a 48 bit seconds counter with +/- 1 30uS up to +/- 1 S drift adjustment every 4048 Seconds. You would need to review the RTC functional description to understand how this feature works. The low frequency oscillator may be an optional clock source for RTC, but fairly sure the RTC is clocked from another source by default. I do not think it is necessary to use the low frequency oscillator since you should be able to adjust the RTC to account for the frequency error of any clock source.

I do not think the GTC has this adjustment capability, so it’s accuracy will be a function of its clock source.

The challenges using AM62X as RTC is that it does not retain the time during a cold reset and we do not have a way of backing the RTC using optimal current.
Noted your inputs on using on-line standard clock for adjustment.

I do not think the GTC has this adjustment capability, so it’s accuracy will be a function of its clock source.

Do you see the internal PLL related errors or Jitter adding to the GTC timer error along with the clock source error.

The PLL output frequency error will approach the reference clock frequency error when measured over long periods of time. However, frequency error will increase if measured over short periods of time. We have only measured frequency error associated with a PLL generated clock over a two periods of time, while trying to understand the impact on MCAN.

While making these measurements, we let the scope accumulate data over night and found the frequency error over a period of several hours was within the tolerance of the crystal.

(+) AM623: sysclk max frequency or epwm max frequency - Processors forum - Processors - TI E2E support forums

I want to know what is the maximum frequency of the clock for this peripheral.

I’ve look at the clocking scheme for this processor and figure out which clock is use and from which pll it comes, but most of the time from my experience, in most processor there is always a maximum frequency and that does not necessarily comes from the theorical maximum frequency of the clock feeding the module.

I’ve look at the available documentation and did not find this information or just missed it.

Could be the system clock feeding de the module (MAIN_SYSCLK0) or the epwm module time-base clock (TBCLK) which is from what I’ve found equal to a maximum of MAIN_SYSCLK0/2?

AM62x was designed and validated to operate MAIN_SYSCLK0 at a fixed frequency of 500 MHz. So the only valid operating frequency for the ePWM module is 500/2 MHz

(+) AM623: ePWM functional clock - Processors forum - Processors - TI E2E support forums

According to the answer in the original thread, ePWM operation clock is 500MHz.
But the latest clock tree tool shows it is 250MHz (MAIN_SYSCLK0 divided by 2).

I guess clock tree is correct and previous answer just means
"ePWM was designed and validated to operate MAIN_SYSCLK0=500MHz, ePWM fclk was 250MHz (MAIN_SYSCLK0 divided by 2)".
Correct?

That is correct.  MAIN_SYSCLK0 = 500MHz and ePWM fclk = 250MHz due to MAIN_SYSCLK0 being divided by 2.

(+) AM620-Q1: Input Slew Rate - Processors forum - Processors - TI E2E support forums

MAIN_SYSCLK0 (SYSCLK0) -- 500 MHz (Derived from MAIN PLL 0)
MCU_SYCLK0 -- 400 MHz (Derived from MCU PLL 0)

Note: You need to use the Clock tree tool to get the clock period for each peripheral where the functional clock period is reference.

There are two output for each EPWM module, can they be independent PWM signal?

    IF yes, so I can get totally 6 independent PWM signals (3 EPWM modules ), right?

EPWM for each instance two independent PWM outputs that can be used in different configurations (with single-edge operation, with
dual-edge symmetric operation or one independent PWM output with dual-edge asymmetric operation)

Am64x EPWM integration

For ECAP, the description in datasheet mentions that Enhanced Capture (ECAP) Input or Auxiliary PWM (APWM) Output

Is APWM not PWM signal?

ECAP When not being used for event capture, its resources can be used to generate a single channel of asymmetrical PWM waveforms.

(+) AM6442: Signal Frequency - Processors forum - Processors - TI E2E support forums

I am currently using ePWM to output analog voltages in a mass production model.

I am using the ePWM peripheral with a time base period register of 512, but I would like to improve the time base period register.

In order to improve the time base period register, it needs to increase the frequency of MAIN_SYSCLK0 clock, but this way will affect big impact to other peripherals,

so please tell me the best way to minimize the effect.

I am using the EPWM demo from sdk_am64x_08_04_00_17.
The ePWM output frequency is 244.1kHz.

I found that the resolution could be improved by changing from up-down mode to up mode. 

questions regarding the clock signal used by ECAP.

What is the frequency of the MAIN_SYSCLK0?

MAIN_SYSCLK0 is 500MHz.  

there are four channels of clock sources: MAIN_SYSCLK0/4, will only the MAIN_SYSCLK0 be used for all three ECAP modules, or is it configurable?

Regards,

Sreenivasa

Hi Board Designers

Inputs related to VDD_CANUART and VDDSHV_CANUART

VDDSHV_CANUART is recommended to be connected to an always-on power source when partial
IO (low-power) mode is implemented. The recommendation is to connect VDDSHV_CANUART to any
valid IO power source (1.8V or 3.3V) when partial IO (low-power) mode is not used.

VDD_CANUART can operate at 0.75V or 0.85V, there is no voltage dependency with the VDD_CORE during
normal operation. The only voltage dependency is during power-up and power-down sequencing.
VDD_CANUART is recommended to be connected to an always-on power source when partial IO (low-power)
mode is used. The recommendation is to connect VDD_CANUART to the same power source as VDD_CORE
when partial IO (low-power) mode is not used.

VDDSHV_CANUART

(3) VDDSHV_CANUART, VDDSHV_MCU, and VDDSHVx [x=0-3] are dual voltage IO supplies which can be operated at 1.8V or 3.3V(3) VDDSHV_CANUART, VDDSHV_MCU, and VDDSHVx [x=0-3] are dual voltage IO supplies which can be operated at 1.8V or 3.3Vdepending on the application requirements.VDDSHV_CANUART shall be connected to an always-on power source when using Partial IO low power mode, or connected to anyvalid IO power source when not using Partial IO low power mode. When VDDSHV_CANUART is not connected to an always-on powersource and is operating at 3.3V, it shall be ramped up with other 3.3V supplies during the 3.3V ramp period defined by this waveform.When any of the VDDSHV_MCU and VDDSHVx [x=0-3] IO supplies are operating at 3.3V, they shall be ramped up with other 3.3Vsupplies during the 3.3V ramp period defined by this waveform.

 (5) VDDSHV_CANUART, VDDSHV_MCU, and VDDSHVx [x=0-3] are dual voltage IO supplies which can be operated at 1.8V or 3.3V
depending on the application requirements.
VDDSHV_CANUART shall be connected to an always-on power source when using Partial IO low power mode, or connected to any
valid IO power source when not using Partial IO low power mode. When VDDSHV_CANUART is not connected to an always-on power
source and is operating at 1.8V, it shall be ramped up with other 1.8V supplies during the 1.8V ramp period defined by this waveform.
When any of the VDDSHV_MCU and VDDSHVx [x=0-3] IO supplies are operating at 1.8V, they shall be ramped up with other 1.8V
supplies during the 1.8V ramp period defined by this waveform.

 VDD_CANUART 

(9) VDD_CANUART shall be connected to an always-on power source when using Partial IO low power mode.
When VDD_CANUART is connected to an always-on power source, the potential applied to VDD_CORE must never be greater than
the potential applied to VDD_CANUART + 0.18V during power-up or power-down. This requires VDD_CANUART to ramp up before
and ramp down after VDD_CORE. VDD_CANUART does not have any ramp requirements beyond the one defined for VDD_CORE.

(10) VDD_CANUART shall be connected to the same power source as VDD_CORE, VDDA_CORE_CSI_DSI, VDDA_CORE_DSI_CLK,
VDDA_CORE_USB, and VDDA_DDR_PLL0 when not using Partial IO low power mode.
VDD_CANUART, VDD_CORE, VDDA_CORE_CSI_DSI, VDDA_CORE_DSI_CLK, VDDA_CORE_USB, and VDDA_DDR_PLL0 can
be operated at 0.75V or 0.85V. When these supplies are operating at 0.75V, they shall be ramped up prior to VDDR_CORE as defined
by this waveform.

(11) VDD_CANUART shall be connected to the same power source as VDD_CORE, VDDA_CORE_CSI_DSI, VDDA_CORE_DSI_CLK,
VDDA_CORE_USB, and VDDA_DDR_PLL0 when not using Partial IO low power mode.
VDD_CANUART, VDD_CORE, VDDA_CORE_CSI_DSI, VDDA_CORE_DSI_CLK, VDDA_CORE_USB, and VDDA_DDR_PLL0 can
be operated at 0.75V or 0.85V. When these supplies are operating at 0.85V, they shall be powered from the same source as
VDDR_CORE and ramped during the 0.85V ramp period defined by this waveform.

Partial IO"  is the low power mode that requires supplying the CANUART rails (VDD_CANUART, VDDSHV_CANUART) with always-ON discrete devices. "Partial IO" is the only AM620-Q1 low power mode that requires turning-OFF external regulators. To get the lowest power consumption when supporting "Partial IO" LPM, the PMIC_LPM_EN0 drives the PMIC enable pin low which triggers an OFF request. Two external discrete LDOs are kept ON to supply the CANUART rails. For "Partial IO" low power mode, VDDSHV_CANUART and VDD_CANUART are the two rails that must stay ON.  Partial IO power consumption is in the uW (<1mW).

What is the purpose for the 'VDD_CANUART' rail on the PDN?

Sreenivasa

Hi Board designers,

FYI, inputs related to probing shorts on assembled board with SOC.

(+) AM2431: Subject: AM2431BSDGHIALVR – VDD_CORE to GND Short After Assembly - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

AM2431BSDGHIALVR – VDD_CORE to GND Short After Assembly

We are facing an issue with the AM2431BSDGHIALVR (ALV 441-ball FCBGA package) during board bring-up.
Below are the detailed observations:

1. Before Assembly:

   • Bare PCB shows open impedance between VDD_CORE and GND.

   • New AM2431 device (unmounted) also shows no short between VDD_CORE and GND.

2. After Assembly (Board not powered On):

   • VDD_CORE and GND become shorted (0 Ω) immediately after reflow.

   • The PCB pads, after device removal, are again open (no short).

   • The removed device continues to show a permanent VDD_CORE–GND short.

3. Verification:

   • The short consistently appears only after reflow.

   • The affected pins are the VDD_CORE group (J10, J12, K11, K9, L12, L8, M11, M9, N10, N8, P9) surrounded by VSS balls under the die center region.

   • No power was applied to the board during or after reflow.

   • PCB footprint follows TI reference (solder mask defined pads).

We suspect a possible internal package-level short between VDD_CORE and GND occurring issue after assembly.

Quick input: Please stop performing the continuity tests since this could likely affect the processor mounted on board and plan to apply power and test the board.

Assuming this is a custom board, if you have any concerns on specific section of the board - please share the schematics in searchable PDF format to do a quick check.

Additional inputs:

You need to be careful using a multimeter to measure impedance of a semiconductor pin. Some multimeters may source a potential that is greater than the recommended operating condition of the pin being measured. If so, there is a chance the measurement could create an Electrical Over Stress (EOS) condition for the pin and damage the device.

There is another concern. If the multimeter sources enough current to power a pin, this is likely a violation of the device power sequence requirements.   

You can get unpredictable results when measuring continuity of a power rail with a multimeter because the potential applied to the device by the multimeter can bias circuits in unpredictable ways. For example, the multimeter may trigger internal ESD protection circuits attached to the power rails.  If this happens the ESD circuits may think the potential applied by the multimeter is an ESD event, where the ESD circuits shunts current to ground.

The results of a continuity test can be misleading unless you power all of the power rails in the sequenced defined in the Power Supply Sequencing section of the datasheet with a ramp rate that is less than the max slew rate defined in the Power Supply Slew Rate Requirements section in the datasheet, and the potential applied never exceeds the voltage limits defined in the Absolute Maximum Ratings table.

Are you trying to measure continuity of the device power rails after it is installed on a PCB along with other components, or before the device is installed on a PCB? The multimeter may be measuring continuity through other components on the PCB if you are trying to make the measurement on an PCB assembly.

Have you tried applying power to the device to see if there is a problem?

I’ve tested the board following the power-up sequence, and the VCC core voltage is now stable.
Thank you for your support.

Regards,

Sreenivasa

Hi Board Designers 

FYI.

(+) AM625-Q1: Clock setting of AM625. - Processors forum - Processors - TI E2E support forums

AM625-Q1: Clock setting of AM625.

clocks = <&k3_clks 55 1>;

The first number '55' is the device id for the module. You can get all the device id for AM62x in the document lined below.

http://gtweb.dal.design.ti.com/nightly_builds/processor-system-firmware/latest/artifacts/output/binaries/system-firmware-public-documentation/5_soc_doc/am62x/devices.html

BTY, this DTS example doesn't seems to be taken from k3-am62-main.dtsi, since AM62x main_timer6 device id is 42, but not 55.

The second number '1' is the click id. The clock id for all the modules in AM62x are documented in the link below.

http://gtweb.dal.design.ti.com/nightly_builds/processor-system-firmware/latest/artifacts/output/binaries/system-firmware-public-documentation/5_soc_doc/am62x/clocks.html

clock-names = "fck";

The clock-names are fixed, please don't change them.

assigned-clocks = <&k3_clks 55 1>;
assigned-clock-parents = <&k3_clks 55 4>; /* 250 MHz, good resolution! */

The "assigned-clocks" and "assigned-clock-parents" are for changing the input clock for a clock mux.

In this case, this DT changes the input clock of fclk to '4'.

Regards,

Sreenivasa

Hi Board Designers, 

Inputs related to interrupt edge slew and pulse duration - Recent customer query resolved

AM2754-Q1: Falling edge interrupt spec.

I am studying the AM275 GPIO interrupt detection capability, specifically for falling-edge triggered interrupts. However, I could not find any relevant timing requirements in the TRM or datasheet.

For AM275 GPIO inputs, is there a minimum low-level pulse width requirement for detecting a falling-edge interrupt?

For example, if a GPIO signal transitions from High to Low and remains Low for approximately 100 ns before returning High, can this pulse reliably trigger a falling-edge interrupt? Or is there a possibility that such a short pulse could be filtered out or missed by the SoC?

Please refer to the electrical characteristics below

I added the links below that you can refer for different IO buffers.

https://www.ti.com/lit/ds/symlink/am2754-q1.pdf#page=63

https://www.ti.com/lit/ds/symlink/am2754-q1.pdf#page=67

Please refer to the notes at the end of electrical characterisitics.

If the interrupt follows the GPIO specification, the processor is expected to detect the interrupt.

We understand your point that as long as the interrupt behavior follows the GPIO specification, the processor is expected to detect the interrupt, and that only edge-triggered interrupts are supported.

However, to clarify our original question, we are specifically trying to understand the minimum timing requirement for reliable edge detection. From our perspective, after a falling edge occurs, the signal typically needs to remain at low level for a certain minimum duration to ensure that the edge can be effectively detected by the processor.

In this regard, we are essentially asking whether there is a defined minimum low pulse width (or equivalent timing parameter) in the GPIO specification that guarantees reliable detection of the falling-edge interrupt.

It seems this aspect may not have been explicitly addressed yet, so we would greatly appreciate it if you could help confirm or point us to the relevant specification or documentation.

Please refer below for 

AM275

AM62P

Note: The GPIO supports only edge interrupt

The document you provided is exactly what I was looking for. I have also found the relevant specification in the latest datasheet.
Although the interrupt behavior is not explicitly mentioned, I assume the related specifications should already be covered there in the capture that you have supplied.

Inputs related to connection of  peripherals between domains.

AM62x

3.1.8 Connectivity Table
Whether an initiator can access certain target or not depends on following factors:
• Whether there is a physical connection between the initiator and the target end point, which is identified with
unique memory address.
• For MCU MCUSSand R5FSS: those native 32bit processors have slightly different memory map view. And
RAT block may need to be programmed to be able to access some target endpoints
• Majority of the target end points are protected by firewall. The firewall needs to be proper configured to make
sure that transactions from the initiator can reach the final target end point.

Partial table added for TRM section and table reference 

10.1.7 Interrupt Connections Summary
Table 10-5. Interrupt Connections Summary

Partial table added for TRM section and table reference 

(+) AM620-Q1: Can MCU access additional I/O Modules which are in MAIN Domain by using RAT? or other method? - Processors forum - Processors - TI E2E support forums

Please refer to the MCU+ SDK developer guide "Accessing main and wakeup domain peripherals from MCU domain"
https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/latest/exports/docs/api_guide_am62x/MAIN_DOMAIN_PERIPHERAL_FROM_MCU.html

For more guidance on when you need to configure the RAT, and when you do not need to configure the RAT, please refer to the AM62x MCU Academy > Region-based Address Translation (RAT)
https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AdKYNwCefo4aecDSowlf0g__AM62-ACADEMY__uiYMDcq__LATEST

AM62Px

Partial table added for TRM section and table reference 

AM62Px MCU+ SDK: Accessing main and wakeup domain peripherals from MCU domain

(5) AM6442: AM64 cross-domain peripheral access : feasibility, restrictions or limitations - Processors forum - Processors - TI E2E support forums

For basic concepts about peripheral allocation across different cores & OSes, please refer to the AM64x Multicore academy > Peripherals:
https://dev.ti.com/tirex/explore/node?node=A__AaRdsK4zRjlChfPY2v0AhQ__AM64-ACADEMY__WI1KRXP__LATEST 

Linux can control the MCU domain peripherals, but they should be disabled in the M4F's Sysconfig settings.

I am sending your thread to another team member to comment on R5F cores controlling MCU domain peripherals. I expect this to be supported, but I am not certain.

At the SoC level, if you want to confirm whether cross-domain functionality is supported, you can refer to the Interrupt Table for the respective core.

For example, if you want to access MCU I2C / MCU UART / MCU SPI peripherals from the MAIN domain, you can check the interrupt table for the R5F core. You’ll see that the interrupts for these peripherals can indeed be routed to the R5F core — which means interrupt-level access is supported.

However, DMA access is not supported for MCU peripherals. This means that neither the R5F nor the M4F core can use DMA with MCU I2C / MCU UART / MCU SPI.

There are no SDK or hardware restrictions in routing these peripheral interrupts to the R5F core, but there is a hardware restriction that prevents using DMA with these MCU peripherals.

When accessing cross-domain peripherals, some latency is expected because transactions must cross the interconnect fabric. Typically, when accessing the above peripherals from the R5F core, you can expect a latency in the range of 170 ns to 310 ns.

(6) AM62P: Main domain MCAN0 being controlled by the MCU domain through RAT (AM62P) - Processors forum - Processors - TI E2E support forums

Region-based Address Translation (RAT)

Regards,

Sreenivasa

Hi Board Designers, 

Inputs related to thermal data/pictures for a given system design (SK or EVM)

We do not provide thermal data but instead we provide customers with technical resources to assist their thermal analysis. Please note, our EVMs typically showcase the full device feature set and the thermal performance is highly dependent on the PCB design, SoC package as well as the power consumption for the specific use case. Here are some of the resources we provide:

• SoC thermal model: AM62P and AM62A thermal models can be found in the corresponding product page on ti.com, under "Design tools & simulation".
• Power Estimation Tool: PET can be found in the corresponding product page on ti.com, under "Design tools & simulation".
• Thermal Design Guide: https://www.ti.com/lit/pdf/sprabi3
• PCB best practices for thermal: https://www.ti.com/lit/an/spradb7/spradb7.pdf

If the concern is the PMIC, I would recommend using the processor PET to estimate the load on each supply group and use a PMIC tool to estimate efficiency and power dissipation. Here is an example PMIC tool: https://dev.ti.com/gallery/info/PMIC/PMIC-Efficiency-Estimator-Tool. 

References to thermal management collaterals

Jacinto 7 Thermal Management Guide - Software Strategies

https://www.ti.com/lit/an/spracz5/spracz5.pdf

Thermal Management of TDA4x and AM6x

https://www.ti.com/lit/an/sdaa146/sdaa146.pdf

Thermal Design Guide for DSP and ARM Application Processors

https://www.ti.com/lit/an/sprabi3b/sprabi3b.pdf

https://www.ti.com/video/3877696191001

Thermal parameters for AM62x

The values provided in the datasheet are based on 2S2P PCB as described the JESD51-9 JEDEC standard, referenced in the table note below the Thermal Resistance Characteristic table.  The thermal resistance of their specific implementation may vary from the values defined in the datasheet.  The recommendation is to perform a thermal analysis of their specific implementation taking into account the entire operating range of their system.  For example, a slight increase in supply voltage can result in a significant increase in power dissipation.

www.ti.com/.../szza017a.pdf
www.ti.com/.../spra953d.pdf
www.ti.com/.../snva419c.pdf
www.ti.com/.../snoaa70.pdf
www.ti.com/.../snva183b.pdf
www.ti.com/.../spradb7.pdf

Regards,

Sreenivasa

Hi Board Designers,

Inputs related to clock loopback

(+) AM5708: Timing eMMC - Processors forum - Processors - TI E2E support forums

 I only see one thing that concerns me. I do not understand the purpose of using a series termination resistor on CMD. I understand the function of the series resistor on CLK if the host is configured to use pad looped back clock as shown in Figure 25-2 of the TRM. I’m having an internal discussion on this topic with some co-workers and will get back to you later if I find a reason it is needed. I’m curious why your product has this resistor. Can you tell me what caused this resistor to be implemented?

As you noted in your previous reply, attaching a scope probe will load the signal and potential slow the rise/fall times. You mentioned a case where adding a probe to CLK alone doesn’t cause a problem. However, Linux fails to start when also adding a probe to data. I suspect the additional load on the signals is causing timing violations. This is more likely to affecting data being read from the eMMC device since the two delays are accumulative to this data path.

I think you now understand how the 25k ohm scope probe can affect the DC value of signals being pulled high with a 47k ohm pull-up resistor. I suspect this is causing problems during initialization of the eMMC device when the host is communicating at 400kHz with open-drain signaling.

As mentioned before, the only timing relationship which can be measured is for data going from the host to the eMMC device. So signal timing cannot be used to validate the eMMC device to host data path. The best way to validate the complete solution is performing a robust functional test that spans the entire voltage/temperature operating ranges expected for your product.

Any time the clock is configured in loop back mode, as shown in Figure 25-2 of the TRM, you potentially have the problem described below.

Using the CLK terminal as an input and output simultaneously creates a signal integrity issue at the CLK terminal.  The source impedance of the output buffer and transmission line impedance of the circuit board etch creates a voltage divider at the CLK terminal during rising and falling edges of the clock.  The voltage at the CLK terminal will change by [VDD * (ZL/(ZL + RS))] when the output buffer toggles and will remain at that voltage until it propagates to the load and the reflection returns.  During this time the amplitude of the CLK terminal may be close to the switching threshold of the input buffer.  When the signal voltage is near the switching threshold, noise can cause the input buffer to generate glitches or invalid transitions on the looped back clock.  This will cause problems for the MMC host.  The figure below is provided to help visualize the circuit topology that creates a voltage divider and resultant voltage waveform.

This problem can be resolved by placing a series termination resistor between the CLK terminal and the transmission line.  This increases the amplitude of the CLK terminal voltage divider step above the switching threshold so noise will not generate any glitches.  This resistor should always be placed as close as possible to the CLK terminal that is sourcing the clock.  The value recommended for this resistor is between 22 and 50 ohms.  As the resistor value increases the amplitude of the voltage divider step will increase which provides more noise margin.  However, the maximum clock speed will decrease as the resistor value increases.  The actual resistor value may need to be determined after the circuit board is fabricated and function of interface has been evaluated.

 Therefore, you always need a series termination resistor on a looped back clock.

CMD is sampled on a clock edge like all of the DAT signals. The CMD and DAT signals can have signal integrity issues as long as they have reached their valid logic level at least the minimum setup time before the respective clock edge.  I’m not aware of any reason CMD should be treated differently than data.

Source Impedance vs Slew rate 

The source impedance of an output buffer has a big impact on the shape of the signal, including the initial launch voltage and resulting voltage steps that occur at each end of the PCB trace when there are additional reflections from the source end of a signal trace after the initial far end reflection returns to the source and bounce back and forth on the PCB trace until it attenuates.  The best way to resolve reflections on a CMOS signal is to have the output source impedance match the PCB trace impedance so the initial reflection from the far end is completely absorbed or attenuated when it gets back to the source.  Not allowing any additional reflections on the PCB trace will help eliminate under-shot and over-shot conditions.

Slew rate control simply slows the transition rate, which can be important for high speed peripherals since they may need to signal to be valid in short periods of time. However, controlling slew rate doesn’t typically have much impact or create under-shot and over-shot conditions on the signals.

Regards,

Sreenivasa

Hi Board Designers,

FYI

(+) AM67A: Request for Guidance on C7x Core Software Development (AM67A) - Processors forum - Processors - TI E2E support forums

AM67A: Request for Guidance on C7x Core Software Development (AM67A)

Please note that TI doesn`t support Beagle Y AI platform on TI E2E forums. Currently AM67A product is designed for C7x DSP to be used as DL compute accelerators. There is currently no roadmap available to enable C7x to be used as a DSP compute accelerator rather than DL accelerator. I am looping in relevant expert from productline who can indicate if there is future plan to support the platform and offer C7x DSP development option on this platform or if they can provide information for partners who may be able to support you outside of the TI standard offering to port/develop code on this platform.

(+) AUDIO-AM62D-EVM: Difference in execution clock cycles between AM62D and AM62A, and C7x - Processors forum - Processors - TI E2E support forums

Based on the original thread, I set both the AM62A-LP and AM62D-EVM to 500MHz and 1000MHz and ran the same measurement app.
As a result, we found that the measured number of execution clock cycles differed even when running the same process on the same EVM.
Also, despite assuming that the c7x performance of the AM62A and AM62D is the same, the results differ between SK-AM62A-LP and AM62D-EVM.

Q1: Could you please explain why the number of execution clock cycles differs even when performing the same process on the same evaluation board?
Our assumption was that the number of measurable clock cycles would be the same for the same process, even if the startup frequency was different.

Q2: Can you please explain why there is a difference between SK-AM62A-LP and AM62D-EVM even when using the same SDK binary?

We perform a simple data copy process as shown below and measure the count value using the CCS Profile clock.

To begin with, the makefile for the freertos libs, defines a SOC specific variable (SOC_AM62DX/AM62AX), which means there might be sections of code in the SDK which use this definition to run SOC specific code. So, when you replace the library, the you end up invoking the code intended for AM62A on AM62D, resulting in better execution cycles.

So, What is that piece of code which results in the difference and why?

You can find the code in kernel/nortos/dpl/c75/CacheP_c75.c:

Notice the cache configuration difference for AM62D/AM275 vs other SOC. For AM62D, the L1 cached is configured to be in Write Through Mode while for AM62A, it is Write Back mode. In our internal testing, we found that the audio related kernels perform significantly better with cache in write through mode rather than the write back mode, on the other hand Cache Write Back works optimally for AM62A use cases.

Regards,

Sreenivasa

Hi Board Designers,

FYI input on low power modes

www.ti.com/.../sprad41.pdf

software-dl.ti.com/.../pm_low_power_modes.html

www.ti.com/.../spradg1.pdf

software-dl.ti.com/.../pm_wakeup_sources.html

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1386942/faq-am62p-how-to-measure-wakeup-latency-for-low-power-modes-on-am62x-a-p 

Regards,

Sreenivasa 

Hi Board Designers,

FYI inputs on processor benchmarks

there is the DDR layout guidelines and the performance benchmarks (tangentially related to DDR in this case) that this customer may find useful. If they've designed a board already they should be familiar with the DDR layout guidelines, but the performance benchmarks may offer some inspiration/ideas for things to use in their validation plan.

AM62x benchmarks: https://www.ti.com/lit/an/sprad45b/sprad45b.pdf

AM62x DDR Layout guidelines: https://www.ti.com/lit/an/sprad06c/sprad06c.pdf

AM64x MCU+ SDK: Benchmarks

Regards,

Sreenivasa

Hi Board Designers,

FYI

Application Note

Accelerating Development with SysConfig using MCU+SDK

Getting Started with Sysconfig Tool

Regards,

Sreenivasa

Hi Board Designers,

Refer inputs related to dynamic voltage switching support.

I see the Core Voltage being 0.75V or 0.85V. Does the AM6x processor families support dynamic voltage scaling 

(+) [FAQ] AM625 / AM623 / AM620-Q1 / AM62Ax / AM62Px / AM62D-Q1 / AM62L / AM64x / AM243x Design Recommendations / Custom board hardware design – Dynamic Voltage Scaling for SOC core (VDD_CORE), Peripheral Core and Analog supplies - Processors forum - Processors - TI E2E support forums

Regards,

Sreenivasa

Hi Board Designers,

Refer inputs related to processor PLL configurations

AM62x

AM62P

Regards,

Sreenivasa

Hi Board Designers, 

AM644x, AM243x, AM62L VDDA_3P3_SDIO (internal LDO input connection) and supply ramp

The VDDA_3P3_SDIO connects to the SD card power switch output.

I assume VDDA_3P3_SDIO is treated as a supply rail and the slew rate requirements for the other supply rails is applicable for the VDDA_3P3_SDIO supply input.

Any thoughts please.

Yes.  The ramp limit is associated with the ESD circuit implemented on each power rail, so the same limit applies to all power rails.

Regards,

Sreenivasa

Hi Board designers,

FYI inputs on supply voltage related behavior

The recommended supply voltage range for AM62P is 3.3V is defined as below.
If out of this range, is it mandatory to reboot the power supply?
Or is it OK to just reset?

Please refer to the below section of the data sheet.

Please refer below FAQ to refer to the latest revision of the data sheet.

 [FAQ] AM625 / AM623 / AM620-Q1 / AM62L / AM62A / AM62P / AM62D-Q1 / AM64x / AM243x Design Recommendations / Custom board hardware design - Current Data sheet revision, updates, revision backup and usage notes 

Regards,

Sreenivasa

HI Board Designers, 

Inputs related to Boot Time Optimizations

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1337330/faq-am6x-uart-boot-and-download-speed-optimizations-25 

AM64x

https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/BOOTFLOW_GUIDE.html

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1176245/processor-sdk-am64x-boot-process-simplification 

AM62x

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_01_10_04/exports/docs/linux/How_to_Guides/Target/How_to_boot_quickly.html

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1283609/sk-am62-linux-bootup-time-optimization 

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1409613/processor-sdk-am62x-which-drivers-tools-i-can-disable-in-the-kernel-menuconfig-in-order-to-speed-up-the-boot 

The boot time optimization can be done in U-Boot, kernel config and device tree, and root filesystem, the exact details will depend on the boot time and software requirement of your project.

First please break down the time consumed in each step of the boot process - uboot loading kernel image, kernel boot, and filesystem init. If you use minicom to connect to your board UART console, you can press 'Ctrl-A N' in minicom, it will add a timestamp on each line of the console message, then you can capture the entire Linux boot log with the timestamps, to understand the time spent on each boot process.

Then you can analyze the boot time consumption to focus on the optimization.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1184539/am625-fast-boot-implementation-recommendation 

AM62A

https://software-dl.ti.com/processor-sdk-linux/esd/AM62AX/09_02_00/exports/docs/linux/How_to_Guides/Target/How_to_boot_quickly.html

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1591476/am67a-fast-booting-boot-media-processes 

AM62P

4.1.12. Boot Time Optimizations — Processor SDK AM62Px Documentation

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1307243/sk-am62a-lp-boot-time-less-than-5-sec 

Regards,

Sreenivasa

HI Board Designers, 

Inputs related UART boot

i2371 — Boot: ROM code may hang in UART boot mode during data transfer

is fixed in later silicon revision 1.1

only the Q1 versions of AM62x are available with PG1.1 revision.  If they didn’t specify Q1, then it is a PG1.0 device

for some  development / evaluation purposes unrelated to the boot process stages, AM62A ROM booting from UART as a primary or backup boot interface still can be used. However, for any production purposes like UniFlash or programing eFuses with OTP Keywriter, please use another ROM primary/backup boot interface, as recommended in the AM62Ax Silicon Errata SR1.0 - advisory i2371. 

If you plan to use UART boot in a (Non-ROM) custom bootloader (SBL,SPL,etc.), please make sure to implement  the sprz544c.pdf Silicon Errata advisory i2310 - software workaround in your custom bootloader.

Customer would like to know the issue reproducibility for reference. Do you know the number?

We don’t really have data on how often the UART errata affects boot. 

I believe we had few devices which exhibited the problem frequently enough to come up with a software workaround. 

The frequent occurrence may indicate the issue could be process related, but that may not be the only issue.

Okay, understood. Customer also understood that they can use UART boot mode at least for development purpose.

(+) TMDS64EVM: Improve Timing OSPI Flash Programming via UART Boot - Processors forum - Processors - TI E2E support forums

(+) AM6442: DEBUG and BOOT Option UART - Processors forum - Processors - TI E2E support forums

(+) AM6442: Unable to boot from USB at power on, but able after load via UART + reset command at U-BOOT - Processors forum - Processors - TI E2E support forums

(+) AM2432: When using USB dfu-util load FW, how to tell whether the AM243x MCU is HS-SE converted or not? - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

(+) AM620-Q1: Clarification on Advisory i2310: Handling UART Boot Timeout Issue on AM62x Processor - Processors forum - Processors - TI E2E support forums

There is no workaround for this issue, so the device may not boot from UART if the condition exists.  The recommendation would be to use another method for flashing.  

The issue is a race condition inside the IP, which can generated at any time, there really arent' any specific conditions that trigger it.

(+) AM625: How to boot Linux on AM6254 using UART Boot mode - Processors forum - Processors - TI E2E support forums

(+) SK-AM62B: AM62B EVM JTAG testing is mul-function? - Processors forum - Processors - TI E2E support forums

(+) [FAQ] AM6x: UART Boot and Download Speed Optimizations (25+% !!!) - Processors forum - Processors - TI E2E support forums

Regards,

Sreenivasa

HI Board Designers, 

Inputs related to eFuse area availability for custom programming - Using Extended OTP

Using Extended OTP — TISCI User Guide

Hardware Configuration

The extended OTP area can have a maximum of 1024 bits. The extended OTP area is organized into rows of bits. The width of each row can vary based on the device. Please refer to the table below for SOC specific details of hardware rows:

On device boot, the data in the OTP area is read into a set of 32 bit memory mapped registers(MMRs). There are 32 such registers to accommodate the maximum number of OTP bits. The width of these registers is always 32 bits irrespective of width of the underlying hardware OTP rows. These registers are only refreshed on a POR of the device and not on a warm reset.

Inputs related to register retaining the value during warm reset::

AM62x

AM62Ax

AM62P

mod_por_rst_n and sys_por_rst_n are PORz reset type (cold)

Mod_g_rst_n is MCU_RESETz type. (warm reset)

At the warm reset case, power supply is not turned OFF, therefore, they think there are some area where they can use to save some context before applying the warm reset. At least, 8bit memory area they need.

Do you know if there is such area?

(+) AM6421: Is there an available Non-volatile memory? - Processors forum - Processors - TI E2E support forums

Customer start the verification of the behavior of PADCONF before/after the warm reset. 

Customer confirmed that it works well as we expected.

 AM6442: Retain certain RAM addresses on warm reset 

mmr registers retain value during warm reset

 AM2434: Retaining variables in RAM across warm reset. 

AM62A3-Q1: MMR register as for MCU instance which is only one we will monitor

Most of the MCU CTRL MMR registers have active parity and need not be monitored periodically. I am attaching the list of registers that have to be monitored below:

MCU_MMR_Register_List.xls

Does the AM64 have any internal non-volatile memory which is persistent between resets, but at the same time is also non-OTP? We are aware of the e-FUSE rows available, but we are looking for a non-permanent storage solution. non-volatile here includes both software and power/cold resets?

There is no on chip, non-volatile memory.

Regards,

Sreenivasa

Hi Board Designers, 

Queries related to the SOC modes 

   1. Restriction on test mode (*Yes: O, No:X (If "Yes'', show "the condition to avoid entering any Test Mode''. 
   2. Restriction on power-up sequence (*Yes: O, No:X (Does it hang up by the particular power-up sequence concerned with rising time or voltage waveform (monotone increase etc.)?
   3. Restriction on power-supply voltage (*Yes: O, No: X (Is there any restriction concerning the sudden change of the voltage even in the range of the guaranteed voltage?
   4. Restriction on ''NC'' pins (*Yes: O, No: X (To be grounded, Not to be connected etc) Another file can be used) 

1. The EMU[1:0] inputs are used to place the device in special test modes.  These inputs must be held in a valid high logic state on the rising edge of MCU_PORz and the rising edge of TRSTn to ensure the device doesn’t enter these test modes.  See the Debug Boot Modes and Boundary Scan Compliance section in the device Technical Reference Manual (TRM).
2. Power supply sequencing is expected for proper operation and the requirements for both power-up and power-down are defined in the Power Supply Requirements.
3. Power supply voltage requirements are defined in the Recommended Operating Conditions table.
4. Yes, reserved pins are expected to be left unconnected.  See the Reserved Signal Descriptions table and the Pin Connectivity Requirements.

Regards,

Sreenivasa 

Hi Board Designers, 

Inputs related to XDS110 connection

https://www.ti.com/tool/TMDSEMU110-U

The XDS110 comes in a package consisting of:

• XDS110 debug pod
• 20-pin debug cable
• 14-pin auxiliary cable
• TI 20-pin to TI 14-pin converter adapter
• TI 20-pin to Arm Cortex® 20-pin converter adapter
• TI 20-pin to Arm Cortex 10-pin converter adapter
• USB cable
• Breakout board for auxiliary cable
• Quick start guide

The recommendation is to use the cable to connect directly to the board (SK or EVM) or connect the cable through one of the converters 

JTAG Connectors and Pinout

https://software-dl.ti.com/ccs/esd/documents/xdsdebugprobes/emu_jtag_connectors.html

 RE: AM6411: JTAG connection problems on custom board 

power on the board in DEVBOOT mode, connect to R5F core directly and see if you are able to write to 0x0 address from the Memory Browser like shown

 RE: AM6412: JTAG Configurations and Usage 

 RE: AM62A7-Q1: Development Boot Mode 

The DEVBOOT mode is intended primarily for the time when we manually want to request loading & running of the TIFS core instead of the ROM automatically taking care of loading & running the TIFS core in other boot modes. Besides this, the more general use case would be:

• Bring up of the board without needing to actually flash anything. The usual boot flow first requires you to flash certain images to SPI or eMMC. Then on changing the bootmodes to the respective boot media, the flashed images boots & initializes the SoCs. However, if DEVBOOT is supported, you can bypass the flashing steps & just require JTAG connection to get started with the development.

 RE: [FAQ] AM2634: Board bring-up FAQ for custom AM263x/AM263Px PCB systems 

Regards,

Sreenivasa

Hi Board Designers, 

Inputs related to recent debug

(+) AM67A: AM67A Custom Hardware - Stuck In Warm Reset Loop - Processors forum - Processors - TI E2E support forums

I am trying to look at the supply rail source for VDDR_CORE rail. Can you please measure the VDDR_CORE voltage level near to the SOC?

I understand from the ROM expert, the ~30ms reset is an indication of internal WDT timer timing overflow and also indicates that the boot is not starting.

Please connect VDD_CORE to VDDR_CORE supply rail and do a check.

Connecting VDD_CORE to VDDR_CORE resolved the warm reset issue. The boot ROM now advances to the correct boot mode.

(+) AM625: Boot Mode Issue - Processors forum - Processors - TI E2E support forums

after adding pull up for J-tag and MCU_RESETz now its booted up.

Regards,

Sreenivasa

Hi Board Designers,

Inputs related to IO supply for IO group connection when not used.

AM2432: Unused SDIO VDDSHV5 decoupling capacitors and connections - Processors forum - Processors - TI E2E support forums

The VDDSHV5 IO power rail supports being turned off for short periods of time and supports dynamic voltage change as required when cycling power to reset an SD Card or when changing the IO operating voltage of an SD Card. However, the VDDSHV5 IO power rail is expected to be always powered for any other use or non-use cases. VDDSHV5 should always be connected to a valid 1.8V or 3.3V IO power supply.

Decoupling capacitors are still required on the VDDSHV5 power rail even when the associated IOs are not used because each IO power rail sources an internal IO bias LDO.

A decoupling capacitor is also required on CAP_VDDS5 when VDDSHV5 is connected to a 3.3V power source. See the note associated with the CAP_VDDS5 signal description in the AM243x datasheet for more information on decoupling capacitor requirements for the CAP_VDDS5 pin.

The custom board design being worked on will not have SDIO MMC1. Reviewing the Connectivity requirements i have the following understanding:

MMC1 Unused. All pins on this interface default GPIO off/off/off. Thes pins will be left as No connects.

SDIO_LDO will not be used. VDDA_3P3_SDIO and CAP_VDDSHV_MMC1 must be connected to Ground. 

VDDSHV5 Looks like it is for MMC1 module. If the MMC1 module is not used How should this Power rail be connected?

Yes. As I mentioned in my previous reply, each power rail is supplying power to an internal IO bias LDO. This is a different LDO than SDIO_LDO which is powered from the VDDA_3P3_SDIO power rail.  It is not possible to leave the internal IO bias LDO unpowered for long durations. We only support it being powered off for a short duration when the VDDSHV5 IO bank is connected to an SD Card and the only way to reset an SD Card is cycle its power. The SD Card pins are not fail-safe so we must turn off the AM243x IOs and any pull-ups connected to the SD Card when its power is cycled off for a short duration to reset the SD Card. This use case is the only time we allow the VDDSHV5 to be powered off while other portions of the device remain powered.

Note: 

The explanation is valid for fixed dual-voltage IO supply for IO group supplies (VDDSHV0, VDDSHV1, VDDSHV2, VDDSHV3, VDDSHV4 (for AM64x) and and Dynamically switched dual-voltage IO supply for IO group supplies  (VDDSHV4, VDDSHV5, VDDSHV6 - depending on the processor family)

Regards,

Sreenivasa

Hi Board Designers,

Inputs related to PBIST and LBIST

General description:

https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/sdl/sdl_docs/userguide/j721e/modules/pbist.html

https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/sdl/sdl_docs/userguide/j721e/modules/lbist.html

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/latest/exports/docs/api_guide_am62x/SDL_PBIST_PAGE.html

PBIST tests the internal memories for permanent faults such as stuck-up bits. The LBIST tests the internal logic circuits present in the SoC.

PBIST and LBIST tests are destructive by nature and hence it is recommended to run these tests at startup before the MCU R5 core is loaded by the SBL.

For MCU R5 specifically, the PBIST would test the R5F internal memories(TCMs and Cache). The LBIST would test the internal R5F circuits. 

The AM62A SBL example already has PBIST and LBIST implemented for the MCU R5 core. You can also take a look at that and the SDL PBIST example for reference. 

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62AX/11_00_00_16/exports/docs/api_guide_am62ax/SDL_PBIST_PAGE.html

AM64x

 LBIST is not present for the A53 core in the AM64 device. The LBIST hardware is only present on the MCU M4 core. In order to test the A53 MMU, the test of MMU will need to be implemented by the system integrator. 

This can be testing using a certain MMU configuration and causing illegal memory accesses or something that will cause TLB mismatches.

AM62P

Power on self test (POST) is a new feature in AM62P from AM62A which is why the TRMs are different. POST is  purely hardware driven self test that runs on device power on when BOOTMODE15=1 and DS_DM_RESET_MASK = 0 as indicated by the diagram.

PBIST and LBIST are software initiated as documented by the link originally provided.

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62AX/09_00_00_19/exports/docs/api_guide_am62ax/SDL_PBIST_PAGE.html

POST and PBIST are not the same. Please do not confuse the webpage documenting PBIST and the TRM diagram documenting POST.

POST is a purely hardware operation that runs only at power on. This is captured in the Figure 6-27. Results are captured into an MMR that will eventually be checked by SDL, but I believe this software is still in development.

PBIST is a software operation that is documented in the webpage originally linked and requires ESM.

AM62Ax

Which chapter of the TRM should be referred for more information on PBIST and LBIST?

We would like to implement PBIST self tests for safety requirement and need inputs on Sitara specific version. So can you please share us some reference document w.r.t tests that can run/restricted/limitation from DMR and MCU R5 respectively.

You can go through the SDL PBIST example for initial reference.

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62AX/10_01_00_33/exports/docs/api_guide_am62ax/SDL_PBIST_PAGE.html

Since PBIST is destructive in nature, you cannot run PBIST for DM R5 as it would disrupt the runtime RM/PM operations. There are no limitations in running the PBIST test for the MCU R5 core.

AM62Ax has only one LBIST instances and that is MCU LBIST. You have to run it from WKUP R5 core.
There is no WKUP LBIST on AM62Ax. There's no LBIST module for Wkup R5 and C7x cores on AM62Ax. We only have an MCU LBIST instance.
MCU LBIST would cover the R5F diagnostics for MCU R5F core only.
It does not test the WKUP domain or C7x cores. The self test mechanisms have to be implemented for these cores.
The LBIST for the MCU R5 core can be triggered from the WKUP R5 core using the SDL_LBIST_selfTest API, as demonstrated in the default SBL examples.

Regarding PBIST, what is tested with this tests

We have only one MCU LBIST instance. 

Regarding PNIST, how we can trigger the tests?

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62AX/latest/exports/docs/api_guide_am62ax/SDL_PBIST_PAGE.html

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62AX/latest/exports/docs/api_guide_am62ax/SDL_LBIST_PAGE.html

You can have a look at the SDL PBIST example for details related to last two questions. 

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62AX/latest/exports/docs/api_guide_am62ax/EXAMPLES_SDL_PBIST.html

Regarding the LBIST: How is it triggered?
The LBIST for the MCU R5 core can be triggered from the WKUP R5 core using the SDL_LBIST_selfTest API, as demonstrated in the default SBL examples.
However, we have recently identified a bug in the AM62Ax MCU R5 LBIST flow, where the debugger fails to connect to the MCU R5F core after executing the LBIST test. We are working on fixing this issue, and the fix is planned for the December 11.2 MCU+SDK
Can you give us more insight about this issue and the plan to fix this mentioned issue?
We were able to root cause and fix the issue. As I had previously mentioned, it is related to the shutdown sequence after the LBIST test. The MCU domain is being left in a transition state after the LBIST test which causes JTAG connection failures. This will be also be included in the 11.3 SDK.

Regarding LBIST, just to be sure I understood it correctly. LBIST just tests the Arm Cortex R5 -Core logic in the MCU Domain, no TCMs or caches, right?

Yes, LBIST just tests the MCU R5 core logic like the MPU and ECC for internal memories. 

TCMs and Cache memories would be tested by PBIST. 

Is also the computing part (Assembly instruction interpretation) of the MCU R5 part of the LBIST Test?

AM243x

Is LBIST supported for the R5F core on the AM243x?

Can the ESM (Error Signaling Module) be used to handle LBIST results and trigger appropriate system responses?

Sreenivasa