https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1682949/am2612-using-psram-with-ospi1/6510374Wed, 14 Oct 2026 10:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1418b15e-5554-49e3-9f56-db8fedaae622Lakshya VermaHi Daisuke-san, Yes, that&#39;s correct. Write operations to the OSPI1 memory-mapped region are supported when the region is configured as strongly ordered in the MPU. Writes are not performed when the region is configured as cacheable, so cached writes are not supported. Reads work with the region either cached or strongly ordered.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689535/tidm-1000-clarification-on-compensation-designer-for-tidm-1000-current-loopWed, 14 Oct 2026 10:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b5361551-2b30-4e42-874f-bf721a680d2fVishwa Balaji SPart Number: TIDM-1000 Other Parts Discussed in Thread: POWERSUITE , SFRA Hi TI Team, While configuring the TIDM-1000 closed-loop project through main.syscfg, the C2000 Compensation Designer GUI: Vienna Rectifier Current Loop opens. Could you please clarify: What plant and operating-point parameters must be provided before using this GUI? Should the plant be based on the default powerSUITE model or measured SFRA data from the actual hardware? What do the Plant, Open Loop, and Compensator curves represent? Which targets should be used for selecting Kp/compensator coefficients, particularly crossover frequency, phase margin, and gain margin? After tuning, how are the generated coefficients transferred into the TIDM-1000 firmware for closed-loop operation? We would also appreciate clarification on whether the current loop should be tuned at a specific input voltage, DC-bus voltage, and load condition. Thanks VishwaSFRApowersuiteTIDM-1000https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689534/am2434-concerns-regarding-the-i2310-issue-on-am243xWed, 14 Oct 2026 10:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:63bc07c2-56d8-4cb6-ac35-585d71c90c0cliang luoPart Number: AM2434 Hi TI Experts, We have a product that, during low-temperature UART communication stress testing, was found to trigger the i2310 fault multiple times. This fault cannot be cleared effectively immediately, causing repeated FIFO timeout interrupt events and resulting in an interrupt storm. If an external watchdog, MAX706, is used to control chip reset, this interrupt storm can prevent the watchdog from being fed in time, thereby causing a system reset. The UART configuration is shown in the figure below, RX trigger level = 1 byte, and the interrupt mode uses &quot;user managed interrupt&quot; mode. The UART interrupt handling is as follows: We recorded the number of timeouts and read it after about ten minutes of testing. The timeout count reached the millions, while other prototype units running the same code either do not exhibit this issue or have only one or two occurrences. Is the i2310 workaround really a verified and reliable solution? Are there any other recommended measures?AM2434Applianceshttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689012/am2632-q1-what-s-the-behavior-when-the-clock-lost/6510360Wed, 14 Oct 2026 10:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9d889607-dce2-49cf-b85e-1b4016e6cf86Sahana H GYes, this timing is ONLY for internal reset propagation to WARMRSTn pad. If the reset is provided externally as an input to WARMRSTn pad, there is no such max limit defined. Regards, Sahanahttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689012/am2632-q1-what-s-the-behavior-when-the-clock-lost/6510357Wed, 14 Oct 2026 10:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ca3cc7da-8505-4f47-9ec4-379e809e64a5Shuqing ZhouHi Sahana, If external WARMRST longer than 16.384ms, after remove the external WARMRST, is device can out of reset successfully? BRs Shuqinghttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689012/am2632-q1-what-s-the-behavior-when-the-clock-lost/6510352Wed, 14 Oct 2026 10:00:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2e4cb939-cbfa-4135-ac7b-ba435a1eb63dSahana H GHi Shuqing, AM2632-Q1 has an internal module that can detect XTAL loss (if limp-mode detection is enabled via LIMP_MODE_EN_XTALCLK_LOSS_EN ) and automatically switch to RC_CLK to keep the CPU and peripherals running. This ensures the CPU continues to operate even if the XTAL Clock fails and can take the system to a safe state. Also note that RC_CLK is not an accurate clock and hence the performance of the system is not guaranteed in Limp mode. [quote userid=&quot;610907&quot; url=&quot;~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689012/am2632-q1-what-s-the-behavior-when-the-clock-lost&quot;]Does triggering a Warm Reset (via WARMRSTn) require the crystal oscillator (XTAL) to be functional? If the XTAL is not working when a Warm Reset is triggered, will the SOC be able to complete the reset sequence and exit reset normally? And what state will the IO pins be left in if the SOC cannot exit reset due to the absence of a clock?[/quote] I&#39;m not sure how external warm reset would help in this scenario as the chip would still not be able to function when it comes out of reset. External monitor needs to power down the MCU using the SAFETY_ERRORn output signal. The recommended way to monitor this scenario is to do the following: 1. Configure the ESM in PWM mode so that ERROR pin can continuously toggle when in normal mode. See Error Signaling Module (ESM) chapter in the Device TRM for more details on this. 2. Implement a Toggle monitor in the external PMIC or a safety monitor. 3. Whenever ESM detects an internal ERROR including XTAL loss, this signal stops toggling. Hence, the external safety monitor can take appropriate action in this scenario. [quote userid=&quot;610907&quot; url=&quot;~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689012/am2632-q1-what-s-the-behavior-when-the-clock-lost&quot;]This has a max timing requirment for WARMRST, if the external watchdog give longer WARMRST signal(&gt; 16384000 ns) and then pull up the WARMRST signal, what will happen? can device release from reset?[/quote] This is limited by the value that can be programmed into the TOP_RCM.WARM_RSTTIME1 register that defines this value. MMR value Delay Value 0 500 ns 1 1us 2 2us 3 4us 4 8us 5 16us 6 32us 7 64us 8 128us 9 256us 10 512us 11 1.024ms 12 2.048ms 13 4.096ms 14 8.192ms 15 16.384ms Regards, Sahanahttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1686184/am13e23019-how-to-disable-the-bsl-invoke-pin/6510350Wed, 14 Oct 2026 09:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:48a850c2-1ac4-49d1-83e6-b9e29e775edfArpit VarahmihirHi Dario, Let me look into the issue and get back to you. Regards Arpithttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1687695/am2612-mcu-sdk-28-01-00-08---flash-xip-regression/6510333Wed, 14 Oct 2026 09:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:eb5bfe30-ac81-4243-8090-e40863943546Lakshya VermaHi Michael, I saw an issue in the project you sent me you forgot to add MPU configuration for the Flash Region 0x60000000. For XIP, you can also refer to this link - AM261x MCU+ SDK: Enabling XIP or eXecute In Place To understand how to configure application for XIPhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1680335/am2732-inquiry-regarding-am2732-hs-se-transition-secure-boot-provisioning-and-technical-specifications/6510274Wed, 14 Oct 2026 08:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a4699a4f-246a-4460-9eb6-6fd6587ae22bJackHi Krithika, Could you please check the status? Thx, Regards, Jackhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689150/am263p4-q1-am263px-mcal-sdk-pbist-positive-test/6510262Wed, 14 Oct 2026 08:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3435fbdc-6f14-49d2-8dd6-2a8f99d9304ajagadish gundavarapuHi Vandhana, I am checking this issue now and will provide you an update as soon as possible. -- Thanks &amp; regards, Jagadish.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1682949/am2612-using-psram-with-ospi1/6510222Wed, 14 Oct 2026 08:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2f794fac-17ef-46f4-aed7-e2933f108af6Daisuke MaedaHi Lakshya-san, Thank you for your reply. I understand that the OSPI1 memory-mapped region cannot be configured as cacheable for write operations. Is it correct that write operations to the OSPI1 memory-mapped region configured as strongly ordered are supported? In the TRM, the memory mapped direct mode is described with the functionality shown below, which appears to indicate that only read operations are supported. AM261x Sitara Microcontrollers Technical Reference Manual (Rev. B) 1.4.13 Octal Serial Peripheral Interface (OSPI) - Page 24 &quot;Memory mapped direct mode of operation for flash data transfer and XIP from flash&quot; 13.3.4.2.5.1.1 OSPI Features - Page 1574 &quot;Memory mapped direct mode of operation for performing flash data transfers and executing code from flash memory.&quot; Best regards, Daisukehttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689153/am263p4-q1-am263px-mcal-sdk-pbist-positive-test-completion/6510201Wed, 14 Oct 2026 07:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:061b874a-8f3d-4b78-ae1c-4782401e5099jagadish gundavarapuHi Vandana, We are checking your issue now and will provide you an update on this. -- Thanks &amp; regards, Jagadish.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1685520/tms570ls0914-can1-is-not-communicating-after-wake-up-from-sleep-mode/6510175Wed, 14 Oct 2026 07:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ed5d8fc2-9f44-4dc4-9d15-11ad8438abdedelna mol A S[quote userid=&quot;45190&quot; url=&quot;~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1685520/tms570ls0914-can1-is-not-communicating-after-wake-up-from-sleep-mode/6496170&quot;] What are the values of the DCAN1 CTL and DCAN1 ES registers right after the failed wake-up? [/quote] During wake-up, we occasionally observe the DCAN1 ES register = 231 (0xE7) immediately after the communication failure.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683585/am2634-am2634-asil-b-safety-mechanisms-selection/6510129Wed, 14 Oct 2026 06:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:77a9b55a-b3b7-419b-bdbb-fffe797f116eCaroline LuThank you very much!https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1686205/tmdscncd263p-edma-issue-hardware-triggered-spi-communication-between-the-am263p4-and-ads127l11/6510123Wed, 14 Oct 2026 06:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a44a8121-8ab1-49c6-9176-8442389a55d1Nilabh AnandHi Wega, While I cannot debug a custom application for you. Below are some thoughts from my side. The eCAP must trigger EDMA via the dedicated ECAP_DMA_INT event (one of CEVT1–CEVT4 selected through ECCTL2[DMAEVTSEL] ). The standard ECAPxINT event only fires once and then stalls until the CPU clears ECFLG[INT] , which would explain why only the first falling edge produces a transfer. Separately, each EDMA PaRAM set must be linked (not left as a single-shot linkAddr = 0xFFFFU ) for transfers to continue automatically after the first event. Second RX word after one trigger: With McSPI FIFO enabled, XFERLEVEL.WCNT sets how many words transfer before the channel halts, and the DMA read request stays asserted as long as unread data sits in the RX register. If a word is already latched in the RX register when the chained RX channel starts, it would be pulled out as the &quot;extra&quot; word. Can you also check if below are as per expectations: Your current ECCTL2[DMAEVTSEL] setting — is DMA sourced from ECAP_DMA_INT or ECAPxINT ? Whether the TX PaRAM link is a copy of the original set (static) or truly re-initializes count/address fields each cycle McSPI0 FIFO/ XFERLEVEL configuration (WCNT, AEL/AFL thresholds) and whether FIFO is enabled How the RX EDMA channel is chained (TCC settings, linked PaRAM reload) relative to the TX channelhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683585/am2634-am2634-asil-b-safety-mechanisms-selection/6510118Wed, 14 Oct 2026 06:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ea623672-265b-4a2e-ae21-6776731cf1f4Sahana H GHi Caroline, You have an AM263 part and the safety manual applicable for it is &quot;SPRUJ14_AM263x_Safety_Manual&quot; from here Secure resources | TI.com . However, this document is not yet updated with ASIL B groups. Hence, you&#39;ll need to refer to &quot; SPRSPB7_AM263P_Safety_Manual.pdf &quot; since AM263 and AM263P are almost identical with a few differences that are called out in AM263 to AM263P Migration Overview (Rev. A) . For QSPI, you can use the following group, which is not part of AM263P: QSPI2, QSPI3, QSPI8, QSPI9, QSPI-T1, QSPI-T2 (Refer to SPRUJ14 for the diagnostics definitions) Let me know if any additional information is needed. Thanks, Sahanahttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1688757/am2432-am2432-dfu-switching-from-ospi-primary-mode-to-usb-dfu-back-up-mode/6510102Wed, 14 Oct 2026 06:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:24ce85d1-4f54-41d9-921c-68c9ff2273e1Borislav LazarkovHello Nilesh, If your image flashing process placed a TIFS/SYSFW certificate (not a complete ROM boot image) at the redundant offset 0x400000, and your erase only restored it to 0xFF bytes, the behavior during a prior successful boot left enough ROM state context to trigger errata i2415 on the next cycle. Instead of erasing 0x400000, place a deliberately invalid but structurally complete ROM boot image (with a valid header format but an intentionally bad CRC/signature) at 0x400000. This causes the ROM to: Check 0x0 → fail (erased). Check 0x400000→ fail cleanly (invalid image, not just TIFS cert) Correctly reset internal state → proceed to USB-DFU backup boot What else I could recommend is: Check what was programmed at 0x400000 before your erase: Was it a full tiboot3.bin (complete ROM boot image)? Or was it a standalone TIFS/SYSFW certificate only? If the latter, this will be your exact trigger for errata i2415. After erasing, use a JTAG debugger to confirm PC location after power-cycle: If PC is at 0x41xxxxxx → ROM failed to boot (stuck in ROM). If PC is at 0x70xxxxxx → SBL launched (USB-DFU reached). Verify full erase of 0x400000 region. Confirm reads back as all 0xFF. Best Regards, Borislav Lazarkovhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689309/am2432-reserved-request-flags-bit-being-checked-in-function-sciclient_service/6510071Wed, 14 Oct 2026 05:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ec018777-70a7-4224-949c-9a2240da92d4Tushar ThakurHi, I have checked the above, the pReqPrm-&gt;flags is masked with both the bit[0-1] but it doesn&#39;t indicate that both bit needs to be set. In the SDK, the bit 0 or TISCI_MSG_FLAG_RESERVED0 flag is not set before any Sciclient_service() API call. This means the TISCI_MSG_FLAG_RESERVED0 flag is not used and is reserved. Regards, Tusharhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1688757/am2432-am2432-dfu-switching-from-ospi-primary-mode-to-usb-dfu-back-up-mode/6510012Wed, 14 Oct 2026 05:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:52ed46b0-f752-4a40-a7ae-008703570617Nilesh ParmarHi Borislav, Thanks for your response. We are erasing on the correct offset as mentioned in your response. Additionally, the back-up boot mode is correctly configured as USB-DFU through boot pins. When we have a blank board, we get success for switching the back-up boot mode because nothing is stored in the OSPI Flash memory. However, once we store the image and erase it, we got stuck in OSPI. Is there anything which require to check for succussing this operation? Kindly update on the same.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1689377/mspm0g5116-bug-in-sysconfig-outputWed, 14 Oct 2026 04:18:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e28ab3aa-7306-4f20-8209-f78bbb54e629Mike BeckerPart Number: MSPM0G5116 Other Parts Discussed in Thread: SYSCONFIG , MSPM0G5187 Hello, There seems to be an issue with how SysConfig (In CSS version 21) when using TinyUSB and the MSPM0G511x micros. The first pic shows the selection made in SysConfig This Picture shows the SysConfig.config file in text this Pic shows the ti_msp_dl_config.c generated notice LFCLK is in the code not LFXT - this generates and error undeclared identifier - this line can not be edited because it is always overwritten at build. This Pic show SysConfig using SOF (not LFXT) This Pic again shows the SysConfig in text (no SOF(which maybe default) or LFCLK) Yet - This Pic shows the generated ti_msp_dl_config.c generated Still adding the wrong information?? If SOF why this line. Cannot edit because build puts it back. It is hell bent on adding the LFCLK line. This Pic show what is used in the dl_sysctl_mspm0g511.h (LFCLK) Undeclared identifier error from ti_msp_dl_config.c Am I goofy and just missing something. With the MSPM0G5187 there appears to be no issue Thanks MikeMSPM0G5116SYSCONFIGConnected peripherals &amp; printersMSPM0G5187