https://e2e.ti.com/support/processors-group/processors/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1674307/tmds64evm-tmds64evm-am64x-sdk-12-01-00-05-03-icssg-eth1-cannot-complete-p2p-peer-delay-exchange-while-sdk-12-00-00-07-04-works/6464212Thu, 27 Aug 2026 00:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a6d58986-2ab7-46b1-a984-9e4e9bb08ac8Mauro RiosHi Daolin Qiu I am experiencing the same issue in 12.01.00.05.03 ( when using with VLAN) Grandmaster --- P2P Transparent Clock Switch --- TMDS64EVM eth2 (ICSSG1). ICSSG transmits correctly, the PTP switch responds correctly, but ICSSG does not pass the received peer-delay multicast traffic to Linux. Is it possible to get access to the ICSSG firmware source code? Some customers, including our company, work closely with the PRU subsystem, so we are wondering why the ICSSG firmware source is not available, while the corresponding PRU firmware for AM57xx is available. This has now become an important factor in our next processor selection. In our case, we need to implement ARP filtering or rate limiting inside the ICSSG firmware. During one of our certification tests, an ARP flood causes a large number of frames to be forwarded to the Linux host, which can overload the Linux networking stack. On AM57xx, we were able to address this by modifying the PRU firmware and filtering the traffic before it reached Linux. With ICSSG, this does not appear to be possible because the firmware is provided only as a binary and the source code is not available. We would therefore like to know whether TI provides ICSSG firmware source access to customers under any licensing, NDA, or support agreement.https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1673211/am623-continuous-reboot-every-90s-resetstatz-after-removing-external-32-768khz-crystal-sdk-11-01-05-03/6464199Thu, 27 Aug 2026 00:33:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3c1f761a-cdb6-42df-bcba-1e741c396ef4Scott Lin2Hi Bin We use default settings same as yours main_rti0: watchdog@e000000 { compatible = &quot;ti,j7-rti-wdt&quot;; reg = ; clocks = ; power-domains = ; assigned-clocks = ; assigned-clock-parents = ; }; Regards, Scotthttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1675925/am5726-cpsw-switch-48484000-switch-cpsw_sl-failed-to-soft-reset/6464144Wed, 26 Aug 2026 23:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c9ce831c-6070-443c-a457-632ce92a6c2bJosue Zamitiz-AyalaHello jiandong hu , Interesting tests I&#39;ve had. I am not able to reproduce the issue with eth0, but I have successfully reproduced the issue with eth1 on am572x GP EVM. e2e.ti.com/.../cpsw_5F00_bug.txt I am guessing this is because my tests were done without any traffic to eth1 so we don&#39;t hit the timeout boundary. I am curious to what your setup is? are you flooding both ports? Anyway, tomorrow I will move to implementing the patch and re-testing. -Josuehttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1676958/am67a-csi2rx-uncorrectable-header-error-causes-permanent-n-byte-pixel-shift-until-stream-restart-sdk-11-02Wed, 26 Aug 2026 22:07:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:532d3969-db73-4488-94fb-36c365146138Evan WilliamsPart Number: AM67A See related thread, TI&#39;s CSI DMA shim driver in 11.02.0 does not tolerate CRC errors consistently. We have two analog channels through an ISL79987 on VC0 and VC1, 2-lane link at 800 MHz, UYVY. The decoder&#39;s analog and MIPI domains are independent, so its FIFO slips roughly one line per second, about 64 ppm. Every ~480 seconds the accumulated slip reaches one active frame and the decoder drops a frame on one VC to re-align. We accept that as unavoidable in an analog capture chain. About 20% of those events leave the capture permanently shifted by 4 pixels, 8 bytes at UYVY, with no resynchronization across any number of subsequent FS/FE boundaries. The key finding: a frame drop on one virtual channel shifts both channels. The error occurs on a single VC, but both DMA contexts shift by the same amount at the same moment. That places the residue upstream of the SHIM_DMACNTX_VC demux, in the shared pixel interface, rather than in any per-context PSI-L endpoint. It is consistent with the rest of what we see: pix_per_clk and SHIM_CNTL_PIX_RST are both device-scoped in struct ti_csi2rx_dev, not per-context. We&#39;ve tried toggling SHIM_DMACNTX_EN on the affected context. It does not recover. The stream freezes and stays frozen until the device is closed and reopened, which suggests the enable bit gates the context without flushing anything, and that it sits downstream of where the corruption actually lives. We see about one visible corruption roughly every 40 minutes per channel. Because the pixel interface is shared and SHIM_CNTL_PIX_RST is global, recovering either channel requires tearing down both. One camera&#39;s error takes out every other camera on the link, which defeats the purpose of virtual channel separation. Is it expected that a truncated packet on one VC desynchronizes the shared pixel interface for all VCs? If so, what isolation does the hardware actually provide between virtual channels on a shared link? What is the correct recovery sequence for a desynchronized pixel interface? Is there any way to resynchronize it without asserting the global SHIM_CNTL_PIX_RST and tearing down every active stream? The shift is 4 pixels, which equals one beat at TI_CSI2RX_MAX_PIX_PER_CLK. Can you confirm whether the pixel interface loses a clock beat when a packet truncates mid-transfer? ti_csi2rx_drain_dma() already exists but is never invoked in response to a CSI error, and cdns-csi2rx.c counts these events with no notification path into the shim. Is that notification path simply unimplemented? Reproduction: stream two analog channels and wait. Budget at least 90 minutes per attempt. No error injection required, and we can test candidate patches same-day.Infotainment &amp; ClusterAM67Ahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1665188/am6422-am64-u-boot-cannot-access-ospi-flash-in-dfu-mode/6464015Wed, 26 Aug 2026 20:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:44dcd8d2-01cf-4608-bed3-d07280225a27Bin LiuHi Zhizhong, [quote userid=&quot;707829&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1665188/am6422-am64-u-boot-cannot-access-ospi-flash-in-dfu-mode/6461312&quot;] To cross-check this solution, I reviewed the SDK11 code. In SDK11, however, I do not see the same removal of OSPI power-domains (or related properties) in the R5 device tree file k3-am642-r5-evm.dts. [/quote] You mentioned that you tested SDK12.01 U-Boot, which doesn&#39;t have the OSPI access issue without removing the power-domains properties in k3-am642-r5-evm.dts, but did you test SDK11 U-Boot to see if it has such failure when power-domains properties are not removed?https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1676938/tda4vh-q1-release-date-for-the-first-jacinto-sdk-12/6464010Wed, 26 Aug 2026 20:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d9521dd6-3e5a-474d-8ab5-76e4e304fa5fSarabesh SrinivasanHi Dominik, it is important to note how the release form and cadence is changing starting with 12.x. From now on we will start with an LTS release of 12.2 targeted tentatively for November time-frame. This means more stable releases are going to be released as SDK offerings to promote customer projects to use more mature SW packages There will still be 12.2.x (12.2.1, 12.2.2) releases for minor bug-fixes and any new features Thanks, Sarabesh S.https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1676949/am2431-am243x-state-of-mcupsdk-core-and-zephyrWed, 26 Aug 2026 20:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:34ba2a2e-7527-4d16-b14b-e9449a8fb384Marko SagadinPart Number: AM2431 Greetings! What is the state of the mcupsdk-core repo? It hasn&#39;t been updated in the 10 months and it has a few PRs opened that seem rudimentary. I am asking because it is mentioned as a part of the setup for the lp_am243x and am243x_evm boards, for example see this setup section . Getting to the point where all mcupsdk-core examples compile cleanly was very error prone, there were some missing files, some dependency projects weren&#39;t correctly referenced (or were referenced at all), etc. Also, how does the mcupsdk-core on GitHub compare to the one that TI provides on it&#39;s download page? Which one would be better suited for development with Zephyr? My overall goal is to determine the level of support maturity of AM243x SOCs and AM64x SOCs inside the Zephyr ecosystem. Best regards MarkoAM2431https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1665497/tda4ven-q1-cold-boot-optimisation-documentation/6464004Wed, 26 Aug 2026 20:21:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:cc25658c-5e06-4790-9ac7-227dd7b587d8Takuma FujiwaraHi Thomas, [quote userid=&quot;699553&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1665497/tda4ven-q1-cold-boot-optimisation-documentation/6463381&quot;]what actual times have you guys seen on the devboard for the TDA4VEN?[/quote] I don&#39;t think we have measurements for TDA4VEN, but architecturally, TDA4VEN is similar to AM62P - they actually share a common device tree. Main difference is TDA4VEN has the SerDes, and high speed interconnects that use the SerDes. So, I would expect times to be similar to AM62P. 5 seconds from just DSS share and Falcon boot sounds quite promising. Other things that I am not sure if you have done already would be: Adding &quot;quiet&quot; to the kernel args to suppress logs Smaller kernel (i.e., taking out kernel drivers for parts of the SoC not used to reduce driver initialization time) Tiny initramfs to reduce filesystem loading Boot media. In general, SD card is slower than eMMC. And eMMC is slower than OSPI. Regards, Takumahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1676417/j784s4xevm-mcspi-fifo-transfer-32-bytes-txx_empty-does-not-re-assert-j784s4-controller-mode/6463958Wed, 26 Aug 2026 19:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1f17960d-2ec6-4151-b089-483bbe7801cfTakuma FujiwaraHi Kevin, SPI5 should be fine, and it should be accessible by Main domain as well as MCU domain. Otherwise, it sounds like the EOT is terminating further TX_EMPTY signals. EOT is usually the signal to stop the channel, so maybe this is an unhandled state that you have hit. What SDK code does is that the AFL and AEL are computed dynamically instead of a fixed size, and when both TX and RX FIFO are used, it is effectively a quarter of the full FIFO (since FIFO is split by two for TX and RX, and each TX and RX FIFO has the FifoTrigLvl set to half of each FIFO). SDK also does some cleaning between transfers by disabling the FIFO buffer, so perhaps there is something dirty between your experiments that is causing the EOT to fire while transfer is ongoing. There is also a corner case handling in SDK for when the transfer is less than the FIFO level, which is handled through shrinking the trigger levels so that small transfers still generate a TX_EMPTY. Otherwise, perhaps there is some initialization that is missed, or some difference in flow. You could compare the call stack between our reference code and your code. Should be relatively easy to do a static analysis using tools. Regards, Takumahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1661532/amic110-ethercat-lrw-access-to-non-interleaved-io-support-provided-by-ti-patch-pru-v1-5-62-is-not-usable/6463934Wed, 26 Aug 2026 19:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b6bde4ca-287a-4be3-b581-4a7fac7175c5Aaron ThomasHi Falk, Currently I&#39;m out of office, and hence, the replies will be delayed. I&#39;ll review the memory dump and match it with the firmware sequence when I&#39;m back in office. [quote userid=&quot;707233&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1661532/amic110-ethercat-lrw-access-to-non-interleaved-io-support-provided-by-ti-patch-pru-v1-5-62-is-not-usable/6463489&quot;]What causes the PRU FW to act differently? Is there a state or some debug info that could tell us what it is waiting for or what went wrong?[/quote] To make sure if the PRU is in some stall state, monitor the ICSS Status (STS) register for the Program Counter (PCTR): [quote userid=&quot;707233&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1661532/amic110-ethercat-lrw-access-to-non-interleaved-io-support-provided-by-ti-patch-pru-v1-5-62-is-not-usable/6463489&quot;]Is the PRU actually receiving any frames from the Ethernet? A frame counter of some sort would be useful.[/quote] These 2 Registers shows the number of EtherCAT frames received on either of the ports: [quote userid=&quot;707233&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1661532/amic110-ethercat-lrw-access-to-non-interleaved-io-support-provided-by-ti-patch-pru-v1-5-62-is-not-usable/6463489&quot;]What makes the PRU forward frames to the SSC (PDI etc.)?[/quote] The PDI reads frames from the MainDevice through the ESC (EtherCAT firmware) if the write from the MainDevice is successful (WKC incremented for the particular command accessing the particular ESC Register/Memory Space). [quote userid=&quot;707233&quot; url=&quot;~/support/processors-group/processors/f/processors-forum/1661532/amic110-ethercat-lrw-access-to-non-interleaved-io-support-provided-by-ti-patch-pru-v1-5-62-is-not-usable/6463489&quot;]Appearently Link Up/Down can be detected via MDIO, should the PRU not change some internal state? Where can it be observed?[/quote] You can refer to the following registers at 0x4A332408 and 0x4A33240C Registers, respectively: : These registers show the PHY address mapped to each PHY connected to the AMIC110x and the corresponding link status (in MDIOLINK Reg). Regards, Aaronhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1673211/am623-continuous-reboot-every-90s-resetstatz-after-removing-external-32-768khz-crystal-sdk-11-01-05-03/6463924Wed, 26 Aug 2026 19:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:58a9c443-bf01-45a0-b227-1748ceefdd62Bin LiuHi Scott, You use the main_rti0 as the watchdog, right? The devicetree defines main_rti0 as following, did you modify its settings? main_rti0: watchdog@e000000 { compatible = &quot;ti,j7-rti-wdt&quot;; reg = ; clocks = ; power-domains = ; assigned-clocks = ; assigned-clock-parents = ; };https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1675456/am625-schematic-review-am625/6463917Wed, 26 Aug 2026 19:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:881e47b9-36bb-4cf8-ae19-27baa569583aKallikuppa SreenivasaHello Ashutosh, MAC interface series resistor Add provision for 22R series resistor tor TDx signals near to the processor MAC interface signals and provision for TDx signals is space is not a constraint near to the EPHY RDX signals. Regards, Sreenivasahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1676938/tda4vh-q1-release-date-for-the-first-jacinto-sdk-12Wed, 26 Aug 2026 19:05:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c580f3d9-09b9-48aa-9785-dceb5e342cbfDominik HallerPart Number: TDA4VH-Q1 Hello, can you give an ETA for the first Jacinto SDK of the SDK12 series? Best regardsTDA4VH-Q1https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1675456/am625-schematic-review-am625/6463905Wed, 26 Aug 2026 18:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5b280825-b9a1-4fad-afbc-98811199eac6Kallikuppa SreenivasaHello Ashutosh, RBias Use 10K Add parallel 22pF This is used for improved ethernet compliance performance Match the clock specification between processor and EPHY Add bulk cap 1uF near to oscillator supply pin Match the clock specification between processor and EPHY Reference implementation proc142B Regards, Sreenivasahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1675456/am625-schematic-review-am625/6463872Wed, 26 Aug 2026 18:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ec721781-da6e-46a4-b609-3062e0efee8cKallikuppa SreenivasaHello Ashutosh, Below are a few value updates that can affect the performance R10 DNI or Delete pullup in case space is a concern R77 Use 10K Refer PROC142B R74 Use 240R Proc124 reference Regards, Sreenivasahttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1675172/tda4vh-q1-main-r5-peripheral-access/6463856Wed, 26 Aug 2026 18:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ac5e0f68-4657-4803-ab35-3fd2c4e2003cJason WhiteAnsil, Where is the top 4 test apps located? I don&#39;t see them under ti-processor-sdk-rtos-j784s4-evm-09_02_00_05. Thanks, Jasonhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1676862/am69a-am69-display-port-4k-resolution-at-60hz/6463820Wed, 26 Aug 2026 17:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:547e90c2-6a25-4b48-b3cd-0e5dff4add73Anastas YordanovHi Randy, Thank you for your query ! I am forwarding it to the responsible person. Thank you ! Best Regards, Anastas Yordanovhttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1676185/am6421-software-vim-post-dispatching-via-hwip_post-on-the-ti-am64x-platform-doesn-t-trigger-interrupt/6463794Wed, 26 Aug 2026 17:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:de001c38-809e-4730-b19d-1157364cb313Tushar ThakurPlease allow some time to review the above code and revert back.https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1676813/tda4ah-q1-emmc-protective-mbr-content-corruption-issue-communication/6463787Wed, 26 Aug 2026 17:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:018c8516-601e-45b6-a700-ae1a85ac531cPraveen RaoHi Jovan, The QNX devb-sdmmc-am65x driver is implemented and owned by Blackberry QNX, hence suggest contacting them for any support related to the driver. Also since there is eMMC which is external to the TDA4VH SoC, have you contacted the eMMC vendor to check if it is a eMMC part issue? Thanks.https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1676146/am62a7-am62a-vpac-viss-near-black-output-with-plain-bayer-sensor-only-pcid-config-that-passes-graph-verify-is-rgb-ir-mode-issue-description/6463770Wed, 26 Aug 2026 17:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d38cf54e-afd8-4c20-9773-adf623c6e695Anshu MadweshHello, Apologies for the delay. This thread has been assigned to the subject matter expert. Please allow some time for a response.