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/1683673/am13e23019-unexpected-interrupt-and-state-in-am13e230x-motor-control-solutionSat, 19 Sep 2026 00:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8d260c7f-fdfb-46e0-b211-d93330c024a3Phuong NguyenPart Number: AM13E23019 I&#39;m currently running the 3-Shunt Hall Sensored FOC motor solution from the AM13E23X SDK with a DRV8323RS driver and BLY172S-24V-4000 motor. Here are the edits I have made to the code to run the motor: Motor_params.h Added the macro block for BLY172S nameplate parameters Updated the MOTOR_PH_Ls_d_H and MOTOR_PH_Ls_q_H aliases Motor_params.c Added const Motor_ParamsType for the BLY172S with the nameplate parameters and copied over the MOTOR_TEKNIC values for all other parameters. Updated motorParams_M1 pointer to point to the new const When I initially startup the debugger through CCS, I always enter the default_handler for unexpected interrupts before motorVars_M1 is set to the parameters I have set. It is not until I restart the debugger where these variables are populated with values. I have gotten the motor to spin with the same code setup, but it will not spin in every iteration. When the motor doesn&#39;t spin and I pass the default_handler, it will never exit calibration (in main.c) for some reason. I have not changed files outside the ones I have listed. I was planning to use TiTune or instaspin to get more accurate parameter identification but I have not been able to get the motor to spin with this. I&#39;m on sdk 26.01.00.03 but is there anything I&#39;m missing in my set up that is triggering the interrupt or keeping me in an indefinite state?AM13E23019Roboticshttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683161/am625-am62x-powervr-guilty-lockup-under-sustained-webgl-gpu-resets-client-never-regains-a-context/6488680Fri, 18 Sep 2026 21:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a14ac9d5-80ff-408f-9a89-9ae3e04b25deShriya SurtiHi Siddhesh, Thank you for providing steps for reproducing the issue, I will let you know of an update as soon as progress has been made. Regards, Shriyahttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683430/am2434-dp83869hmrgzr-phy-address/6488632Fri, 18 Sep 2026 20:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:69b2c420-9232-4cc7-abc3-9a4823afc4f7Anastas YordanovHello Shashank, Thank you for your query ! From the reused schematic of the LP-AM243 EVM (SPRR433D.ZIP available at https://www.ti.com/tool/LP-AM243) I understand that you have attached two DP83869 Ethernet PHYs to the two RGMII ports of the PRU-ICSS1 GeMAC controller -&gt; PRG1_RGMII1 and PRG1_RGMII2 respectively. I am referring to the latest LP-AM243 schematic revision PROC109_E3. You have the MDIO ports of the two DP83869 PHYs attached to the same PRU-ICSS1 GeMAC controller MDIO bus. Q1. Have you populated the TS3DDR3812RUAR multiplexer on your board ? If yes, is there a chance that you enabled the RX/TX connections from the PHY0 (not OK) to the CPSW3g CPSW_RGMII1 port instead of to the PRU_ICSS1 GeMAC PRG1_RGMII1. Could you please check ? Q2. Is it possible that you used invalid bootstrapping resistor combination to select the PHY address (reported as 0 in the log). PHY address assignment to 0x0 on MDIO bus is not recommended (although permissible by Clause 22). Please try to use 0x3, updating the bootstrap address configuration as shown in the the Figure, AM64x/AM243x Ethernet Interfaces - ICSSG1 Ethernet Strap Settings of the Section, Ethernet Interface / Section, DP83869 PHY Default Configuration / document: https://www.ti.com/lit/ug/spruj63d/spruj63d.pdf#page=42 - EVM User&#39;s Guide: TMDS243EVM TMDS64EVM AM64x/AM243x Evaluation Module. Q3. There is an Advisory Note i2329 in the AM64x/AM243x Silicon Errata (valid for your AM2434BSFFHIALXR silicon revision 2.0 processor). If A1 and A2 show that your configuration is OK, are you sure that the i2329 workaround is applied in the PRU-ICSS GeMAC controller MDIO driver. For the PRU-ICSSG it shall be done as follows: I hope this helps find the issue with PHY0. Thank you ! Best Regards, Anastas Yordanovhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683661/am2612-am2612-zcz-vs-zej-package-production-lifecycle-and-supply-guidanceFri, 18 Sep 2026 20:12:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:360c0995-c2df-4721-9344-805a74cac837JackPart Number: AM2612 Hello TI Team, We are selecting the package for a new AM2612-based industrial product and are considering both the ZCZ and ZEJ package options. As this product is expected to enter volume production and may have increasing demand in the future, we would like to understand the long-term production and supply considerations before finalizing the package selection. Could you please clarify the following? Are both the AM2612 ZCZ and ZEJ package options planned for long-term production availability? For a new industrial product design, does TI recommend either ZCZ or ZEJ as the preferred package option? If so, please explain the key reasons for the recommendation. Are there any lifecycle, supply continuity, manufacturing, lead-time, or allocation considerations that differ between ZCZ and ZEJ? Is either package expected to have a different product longevity commitment or supply-risk profile? Are there any package-specific considerations that TI recommends evaluating before production release, such as: Package availability and sourcing PCB manufacturing and assembly considerations Thermal performance Future device roadmap compatibility Recommended package choice for high-volume industrial production Our objective is to select the most suitable AM2612 package for a long-life industrial product and minimize potential supply or lifecycle risks during mass production. Thank you for your guidance. Best Regards, JackAM2612https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683657/am2612-am2612-profinet-device-support-on-icssm1-and-zej-package-for-2-port-designFri, 18 Sep 2026 19:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:799ed411-3bc1-4793-a77f-e4ed4be53a37JackPart Number: AM2612 Other Parts Discussed in Thread: SYSCONFIG , LP-AM261 Hello TI Team, We are developing a custom AM2612 board based on the Industrial Communications SDK PROFINET Device example. The current PROFINET Device example is configured to use ICSSM0. In our current Custom SysConfig configuration, PROFINET uses ICSSM0, while General Ethernet / ICSS-EMAC uses ICSSM1. For our final custom board architecture, we are considering moving the PROFINET Device application from ICSSM0 to ICSSM1. We would also like to evaluate the ZEJ package for a future production board because of PCB area and pin-assignment constraints. Could you please clarify the following? PROFINET on ICSSM1 Is the current use of ICSSM0 in the PROFINET Device example only due to TI validation coverage, or is the PROFINET firmware/FWHAL architecture functionally tied to ICSSM0? Is it technically possible to run the PROFINET Device application on ICSSM1? If supported, what changes are required for migration from ICSSM0 to ICSSM1? SysConfig configuration Board and pinmux configuration Generated source files Interrupt and event mapping FWHAL configuration PROFINET stack adaptation PRU firmware selection or build configuration Does TI officially support and validate PROFINET Device operation on ICSSM1, including 2-port operation? If not, please clarify whether this would be considered a customer-owned implementation. ZEJ package support for 2-port PROFINET Device We have already completed basic PROFINET testing using the LP-AM261 platform. For the production board, we are considering the AM2612 ZEJ package. Could you please confirm: Are there any known limitations when implementing a 2-port PROFINET Device with the ZEJ package? Are there any mandatory ICSSM/PROFINET signals available on ZCZ but unavailable on ZEJ? Which ICSSM instance, ICSSM0 or ICSSM1, is recommended for a 2-port PROFINET Device design using the ZEJ package? Does TI provide a recommended pin assignment, pinmux example, reference design, or validated custom-board configuration for ZEJ package based 2-port PROFINET? Are there additional restrictions related to Ethernet PHY reset, MDIO, reference clock, interrupt/event routing, or PRU-ICSS pin assignment when using ZEJ? Our goal is to build a custom 2-port PROFINET Device board using the actual ZCZ or ZEJ package pin assignment, rather than retaining the LP-AM261 board configuration. Thank you for your guidance. Best Regards, Jack ChaLP-AM261SYSCONFIGAM2612https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1677815/am2612-am2612-package-selection-zcz-vs-zej-industrial-communications-ospi-level-shifter-icssm-profinet-lwip-sysconfig/6488620Fri, 18 Sep 2026 19:54:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:574991be-c5eb-4ba9-a8e1-2ca2be99f5e8JackHi Shaunak Please let me ass question via the new thread. AM2612: AM2612 Custom ZCZ/ZEJ Board SysConfig Support and pinmux.syscfg.js Error Thanks. Best Regards, Jackhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683656/am2612-am2612-custom-zcz-zej-board-sysconfig-support-and-pinmux-syscfg-js-errorFri, 18 Sep 2026 19:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f6c8b0c7-bbad-42aa-8ef3-2ec29a5efc7bJackPart Number: AM2612 Other Parts Discussed in Thread: LP-AM261 , SYSCONFIG Hi TI. ( Shaunak ) We are developing a custom AM2612 board using the ZCZ or ZEJ package and are trying to generate source code from the LP-AM261 based PROFINET example. When opening or creating a SysConfig configuration, we see the following error: No such resource: /drivers/pinmux/pinmux.syscfg.js We are currently using Industrial Communications SDK for AM261x version 2026.00.00.06 and SysConfig version 1.28.1. We found that the 2026.00.00 SDK release notes list SysConfig 1.27.0 build 4565 as the supported version. Please confirm whether using SysConfig 1.28.1 is unsupported and whether reverting to SysConfig 1.27.0 is the recommended workaround. In addition, could you please clarify: Is there a planned SDK or SysConfig release that fixes the missing /drivers/pinmux/pinmux.syscfg.js resource issue? Please share the target version or ETA if available. Can a custom AM2612 ZCZ or ZEJ board be created from scratch in SysConfig, with custom package-specific pin assignments, without modifying SDK JavaScript files or metadata? What is the recommended procedure to migrate an LP-AM261 PROFINET example to a custom ZCZ/ZEJ PCB while retaining normal SysConfig source generation? Are there any mandatory board configuration changes beyond pinmux for PRU-ICSS/PROFINET, such as PHY, reset, clock, EEPROM, or board module settings? Our objective is to generate the SysConfig source files based on the actual custom PCB pin assignment rather than retaining the LP-AM261 board definition. P.S. Let me attach the sysconfig file. e2e.ti.com/.../260901_5F00_AM2612_5F00_ZCZ_5F00_V.zip Thanks. Best Regards, JackIndustrial AutomationLP-AM261SYSCONFIGAM2612https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1677815/am2612-am2612-package-selection-zcz-vs-zej-industrial-communications-ospi-level-shifter-icssm-profinet-lwip-sysconfig/6488608Fri, 18 Sep 2026 19:41:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:810797c4-0f10-43e5-8be9-45d03900e28eJackHi Fleenor, Thanks for your support. We found that the latest AM261x datasheet lists VDDS1833_FLASH0 and VDDS1833_FLASH1 as 1.8-V / 3.3-V Flash I/O supplies also for the ZCZ package. Please confirm that, for a 1.8-V OSPI NOR Flash or OSPI PSRAM on AM2612 ZCZ, the recommended implementation is to power the applicable Flash I/O domain at 1.8 V and connect the OSPI signals directly without an external level shifter. Please also provide the recommended ZCZ pinmux/pad selection for OSPI0 and OSPI1 operating at 1.8 V, including CLK, CSn, DQ[7:0], DQS, and RESET. If TI still recommends an external level shifter for a 3.3-V OSPI bank to a 1.8-V memory, please provide a validated reference topology for 133-MHz DDR operation. The solution must support bidirectional DQ direction turn-around without a software-controlled DIR signal and must clarify support for ROM OSPI boot, XIP, PHY tuning, and DQS-to-DQ skew budget. Thanks. Best Regards, Jackhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1666674/tms570lc4357-dcan-27-erratum-questions/6488513Fri, 18 Sep 2026 18:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ac16837b-ead8-4af5-ac62-2dc9cceaf692QJ WangYour PrtAssg0 = 0x04444000 register configuration is perfectly correct for your intended mapping. This register assigns read/write ports to channels in 4-bit blocks: 0 for DMA_CH0 (ADC, Read Port A, Write Port A) 4 for DMA_CH1 (DCAN1, Read Port B, Write Port A) 4 for DMA_CH2 (DCAN2, Read Port B, Write Port A) 4 for DMA_CH3 (DCAN3, Read Port B, Write Port A) 4 for DMA_CH4 (DCAN4, Read Port B, Write Port A) The clearing of the bits in HWCHENAS is a built-in behavior governed by control packet&#39;s AUTOINIT. The HWCHENAS bit is not cleared if AUTOINIT is ON, but It is cleared at the end of a block transfer if AUTOINIT is OFF. You are correct. The data sheet has warning that &quot;only one of these DMA request sources is enabled at any time&quot; means you cannot safely have both the MibADC2 G1 hardware event and the DCAN1 IF3 hardware event driving the internal logic simultaneously. [quote userid=&quot;553769&quot; url=&quot;~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1666674/tms570lc4357-dcan-27-erratum-questions/6488361&quot;]Is it possible to remap only the DCAN1 IF3 request to a different channel from MibADC2 G1? [/quote] Unfortunately, you cannot shift a peripheral&#39;s hardwired DMA Request Line number . DCAN1 IF3 is permanently tied to DMAREQ[16] at the silicon layer. Because both DCAN1 IF3 and MibADC2 G1 share DMAREQ[16], if MibADC2 G1 fires, it will trigger whatever DMA Channel is assigned to Line 16. To make your DCAN1 IF3 DMA work, you must ensure that MibADC2 G1 DMA generation is completely disabled in your ADC configuration. M oving your ADC operations to MibADC2 G2 or Event Group completely avoids the hardware DMA conflict with DCAN1 IF3.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1682096/mspm0-sdk-mspm0-sdk-access-issue/6488488Fri, 18 Sep 2026 17:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3883e5b3-f267-40a9-af96-9e0e86dd14cfDiego Abad SajaminHi Kostyantyn, Sorry to hear that. You can also download the full SDK through this link in a zip file fashion: https://dev.ti.com/tirex/explore/node?isTheia=false&amp;node=A__AEIJm0rwIeU.2P1OBWwlaA__MSPM0-SDK__a3PaaoK__LATEST Best Regards, Diego Abadhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1680184/am263p4-q1-am263p4-adc-sequential-and-simultaneous-sampling/6488410Fri, 18 Sep 2026 16:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a9b73197-5f46-4fe2-a90f-1ca2a9bf4e41Kudra BarutiCan you please provide a bit more information on this. I do not have enough to go on.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683586/lp-am261-spi-unable-to-modify-the-input-clock-frequency/6488366Fri, 18 Sep 2026 16:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e45e4deb-4962-4497-b006-5f13d0b748c1FleenorHi Sean, Thanks for the very thorough root-cause analysis — your math and driver trace are correct, and I can add some useful context that points strongly toward this being a SysConfig/MCU+ SDK code-generation defect rather than something you&#39;re missing on the configuration side. Confirming your clock math Per the AM261x TRM (MCSPI clock ratio granularity section), when CLKG=1 (clock granularity = 1 cycle), FRATIO = EXTCLK : CLKD + 1 , and the resulting SPICLK = inputClkFreq / FRATIO. With inputClkFreq = 50 , 000 , 000 and a target bitRate of 12,000,000, FRATIO rounds up to 5 (not a power of 2), giving exactly the 10 MHz you measured (50 MHz / 5). This is expected behavior of MCSPI_ setClkConfig ( ) for a 50 MHz source — 50 MHz simply cannot divide evenly to 12 MHz. Your identification that a 48 MHz source clock is needed to hit exactly 12 MHz (48/4 = 12) is correct. On selecting DPLL_PER_HSDIV0_CLKOUT0 This is a legitimate configuration path — the AM261x TRM&#39;s clock mux table explicitly lists SPI0_CLK_MUX with DPLL_PER_HSDIV0_CLKOUT0 as option 3 for MCSPI0_CLK_SRC_SEL , alongside SYS_CLK, EXT_REFCLK, XTALCLK, etc. So functionally, your approach of switching SPI0&#39;s clock source away from SYSCLK to reach 48 MHz is sound per the hardware documentation. This looks like a known class of SysConfig codegen bug on AM261x There is a very similar, previously-confirmed bug on AM261x involving a different peripheral&#39;s clock-tree wiring: in that case, the RTI clock source mux address was miscalculated inside the SDK&#39;s rti_am261x.syscfg.js (an incorrect address offset, 0x118 instead of 0x140 ), which caused the RTI to silently fall back to its default 25 MHz clock source instead of the one selected in the ClockTree GUI — even though the SysConfig GUI showed the &quot;correct&quot; configuration and the .syscfg file captured the selection properly. TI confirmed it as an SDK bug, provided a manual .syscfg.js edit as a workaround, and raised an internal fix for the SDK. Your symptom matches this pattern closely: the ClockTree mux selection is being correctly written into your example.syscfg ( mux27.inputSelect = &quot;DPLL_PER_HSDIV0_CLKOUT0&quot; ; ), but the generated ti_drivers_config.c is not picking up the resolved clock frequency for gMcspiAttrs.inputClkFreq — it stays hardcoded at 50,000,000 regardless of any ClockTree change (mux selection, divider, etc.). That strongly suggests the MCSPI driver&#39;s .syscfg.js /template is either not correctly querying the resolved SPI0_CLK_GCM_CLKSRC_SEL → SPI0_CLK_GCM_CLKDIV chain output, or has a stale/incorrect reference (similar to the RTI address bug) when computing the value written into inputClkFreq . This is not something you&#39;re missing — the SysConfig ClockTree tool is documented as being intended to have exactly this kind of change propagate through to generated code, and your steps (changing clock source in ClockTree, verifying the .syscfg diff, checking the generated C file) are the correct way to diagnose it. Recommended next steps As a workaround, you can bypass the code-gen issue entirely by manually overriding inputClkFreq in gMcspiAttrs after generation (e.g., edit the generated ti_drivers_config.c directly, or override the attribute at runtime before calling MCSPI_ open ( ) ), setting it to the actual resolved SPI0 input clock frequency (48,000,000 once your DPLL_PER_HSDIV0_CLKOUT0 path is active). This will get you working 12 MHz SPI transfers immediately without waiting on an SDK fix. I will flag this explicitly as a suspected bug and file an internal ticket — given the precedent above, this looks like it needs a fix in the MCSPI module&#39;s .meta / .syscfg.js files (likely in mcu_plus_sdk/source/sysconfig/drivers/.meta/mcspi/... ) to correctly re-resolve inputClkFreq from the ClockTree output rather than using a fixed/default value. Please also share exact repro steps (SysConfig ClockTree screenshots + resulting .syscfg diff + generated ti_drivers_config.c diff) if you haven&#39;t already — this is exactly the level of detail that got the analogous RTI issue root-caused and fixed quickly. Let me know if the manual inputClkFreq override workaround gets you unblocked in the meantime. Best Regards, Zackary Fleenorhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1666674/tms570lc4357-dcan-27-erratum-questions/6488361Fri, 18 Sep 2026 16:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0001443f-d7d7-4438-b17c-d53c5402ab03Cameron FruitYes, I&#39;m using DCAN4 for my test. Are you implying that I can only enable one port destination/source address combination at a time? In other words, would I need to enable each CAN channel&#39;s source/destination in turn for DMA to perform the read? Is there a problem with PrtAssg0 = 0x04444000? I wasn&#39;t sure what your comment meant. I notice in the register dump (attached previously) that bit 4 of the DMA HWCHENAS register is set before the data was received but afterwards it is cleared. I don&#39;t explicitly clear the bit in the software. I&#39;ve tried this repeatedly in the debugger and I usually see HWCHENAS bit 4 is set (value = 0x0000001D) even after receiving CAN data, but very occasionally bit 4 gets cleared to 0 as in the above data. Either way, DMA does not successfully read the data. The code does not explicitly clear bit 4. Any ideas what could be causing this behavior? Interestingly, we are using DMA CH0 for reading ADC, and the HWCHENAS bit 0 is set at configuration of DMA for ADC but it also seems to be getting cleared somewhere. However, this does not seem to impact the operation of the ADC DMA, which is working correctly. One more comment: My intent is to use only DMA CH1 for DCAN1 as we are currently already using DMA CH0 for reading ADC2 data. There is a note in the MCU data sheet in the Default DMA Request Map section, &quot;The application must ensure that only one of these DMA request sources is enabled at any time.&quot; This looks like it may be a problem since DMAREQ[16] is the request line assigned to both DCAN1 IF3 and MibADC2 G1. Is it possible to remap only the DCAN1 IF3 request to a different channel from MibADC2 G1?https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1672865/am2432-am2432-dlr-network-fault-under-large-traffic-conditions/6488272Fri, 18 Sep 2026 14:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c95bcb96-e129-4fda-8f31-7ac166d34625Archit DevHi Wang, Thanks for testing this. To summarize the current status: Fixed issues Write ptr corruption Open issues Junk packets in the network still seen on Inovance side(though the fixes made in version 07 have reduced the frequency) Not seen on the TI side Short frames being forwarded by the DUT During the debug today we&#39;ve identified and some issues on the transmit path and running some tests currently. I&#39;ll keep you updated here about the findings. Regards, Archithttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683586/lp-am261-spi-unable-to-modify-the-input-clock-frequencyFri, 18 Sep 2026 13:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f281f68b-1a23-43b9-8fe1-4734770346e6Sean MoffattPart Number: LP-AM261 Other Parts Discussed in Thread: CCSTUDIO , SYSCONFIG Device: LP-AM261 Evaluation board SDK: MCU+ SDK for AM261x 26.0.0.06 CCStudio: 21.0.0.14 SysConfig: 1.27.0 Using the MCSPI Performance 8 Bit example provided by the MCU+ SDK, I&#39;m attempting to transmit at 12 MHz with SPI0, however it will only transmit at 10 MHz. The CONFIG_MCSPI0 Channel Configuration 0 has the Clock Frequency set to 12,000,000. The initial setup of SPI0&#39;s clock is to use SYSCLK with SPI0_CLK_GRM_CLKDIV set to 5, to have SPI0_CLK of 50.00MHz. This generates a Release/syscfg/ti_drivers_config.c gMcspiAttrs with the inputClkFreq set to 50,000,000. /* MCSPI atrributes */ static MCSPI_Attrs gMcspiAttrs[CONFIG_MCSPI_NUM_INSTANCES] = { { .baseAddr = CSL_MCSPI0_U_BASE, .inputClkFreq = 50000000U, .intrNum = CSLR_R5FSS0_CORE0_INTR_MCSPI0_INTR, .operMode = MCSPI_OPER_MODE_POLLED, .intrPriority = 4U, .chMode = MCSPI_CH_MODE_SINGLE, .pinMode = MCSPI_PINMODE_4PIN, .initDelay = MCSPI_INITDLY_0, .multiWordAccess = FALSE, }, }; However when measured via an oscilloscope the SPI0_CLK signal is only at 10 MHz, which appears to be due to MCU+ SDK McSPI driver&#39;s MCSPI_setClkConfig function. static void MCSPI_setClkConfig(uint32_t baseAddr, uint32_t chNum, uint32_t inputClkFreq, uint32_t bitRate) { uint32_t fRatio; uint32_t clkD; uint32_t extClk; /* Calculate the value of fRatio. */ fRatio = inputClkFreq / bitRate; if(((inputClkFreq % bitRate) != 0U) &amp;&amp; (fRatio &gt; 4U; clkD = (fRatio - 1U) &amp; (uint32_t) MCSPI_CLKD_MASK; /* Set the extClk field */ CSL_REG32_FINS( baseAddr + MCSPI_CHCTRL(chNum), MCSPI_CH0CTRL_EXTCLK, extClk); } else { /* Clock granularity of power of 2 */ CSL_REG32_FINS( baseAddr + MCSPI_CHCONF(chNum), MCSPI_CH0CONF_CLKG, CSL_MCSPI_CH0CONF_CLKG_POWERTWO); clkD = 0U; while (1U != fRatio) { fRatio &gt;&gt;= 1U; clkD++; } } /* Configure the clkD field */ CSL_REG32_FINS(baseAddr + MCSPI_CHCONF(chNum), MCSPI_CH0CONF_CLKD, clkD); return; } Since the inputClkFreq is 50,000,000 and bitRate is 12,000,000, the ratio is not a power of 2, therefore the Clock ration extension is used. This results in EXTCLK of 0, CLKD of 4, which creates a clock ratio of CLKD + 1, resulting in SPI0&#39;s clock being 10MHz. To have the desired 12 MHz rate, the input clock for SPI0 should be 48 MHz, which should be possible by selecting DPLL_PER_HSDIV0_CLKOUT0 for SPI0_CLK_GCM_CLKSRC_SEL. However this change appears to have no affect on the generated a Release/syscfg/ti_drivers_config.c gMcspiAttrs as the the inputClkFreq set to 50,000,000, which results in the SPI0 clock still being 10MHz. In fact attempting any changes to SPI0&#39;s clock, via SysConfig&#39;s ClockTree tool, such as modifying the SPI0_CLK_GCM_CLKDIV value do not appear to impact the generated Release/syscfg/ti_drivers_config.c gMcspiAttrs&#39;s inputClkFreq parameter. I can confirm when changing the SPI0_CLK_GCM_CLKSRC_SEL to DPLL_PER_HSDIV0_CLKOUT0 the following entry is added to my example.syscfg file. const mux27 = system.clockTree[&quot;SPI0_CLK_GCM_CLKSRC_SEL&quot;]; mux27.inputSelect = &quot;DPLL_PER_HSDIV0_CLKOUT0&quot;; Is this a bug within SysConfig/ClockTree/MCU+ SDK or am I missing something?LP-AM261CCSTUDIOAppliancesSYSCONFIGhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1681400/audio-am275-evm-cs3571400-audio-am275-evm-got-broken/6488234Fri, 18 Sep 2026 13:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:acca4aeb-98f4-4c88-804c-3af0681bb050Matthias LessingHi Randy, The board was powered using momax UA10 adapter using PD USB-C output C2 capable of delivering up to 35W. Adapter has been used with various devices across many years without issues or damage to any other device. Can you confirm that the power-delivery negotiation is properly implemented on the TI-PD controller? The large inductor L24 is not damaged as it looks exactly like inductor on the other board which is running fine. Both &quot;out-of-the-box&quot; have some manufacturing residue glue/paste-like piece that can be simply removed. The AM275x was the only device connected. It seems as if it failed PD negotiation with the adapter. Indeed PD should have negotiated a safe 5V baseline before allocating power. The user guide states the board requires a source capable of more than 15W, with no warning that a higher-wattage USB-PD supply is incompatible or dangerous. BR Matthiashttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683585/am2634-am2634-asil-b-safety-mechanisms-selectionFri, 18 Sep 2026 13:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6d402b8e-dc55-4778-8f3e-7e07b80ef02dCaroline LuPart Number: AM2634 Dear all, P/N: XAM2634AOLFHMZCZQ HMEDA file: AM263P_FMEDA_ZCZ_C_AUTO.xlsm I am using the MCU for several ASIL B applications. So, I use the GUI of the HW FMEDA which &quot;configure all ASIL-B&quot;. My question now where to find the list of safety mechanisms behind the xxxx.ASILB.xxxx.groupx in the FMEDA that we need to implement/configure to apply TI recommendations. In the safety manual there are diagnostic groups and categories but not explicitly those ASIL B groups. Thank youAM2634https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1677923/mspm0-sdk-connection-to-mspm0-core-failed/6488158Fri, 18 Sep 2026 11:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bd188e6e-47c5-477e-a5c7-472f19b7413cNandini VKHi Sal Ye , The following is the original content from the bsl_software_invoke_app_demo_can project&#39;s .cmd file: -uinterruptVectors --stack_size= 512 MEMORY { FLASH (RX) : origin = 0x00000000 , length = 0x00001000 FLASH2 (RX) : origin = 0x00003800 , length = 0x0001C800 SRAM (RWX) : origin = 0x20200000 , length = 0x00008000 BCR_CONFIG (R) : origin = 0x41C00000 , length = 0x00000080 BSL_CONFIG (R) : origin = 0x41C00100 , length = 0x00000080 } SECTIONS { .intvecs: &gt; 0x00000000 .text : palign ( 8 ) {} &gt; FLASH | FLASH2 . const : palign ( 8 ) {} &gt;&gt; FLASH | FLASH2 .cinit : palign ( 8 ) {} &gt; FLASH | FLASH2 .pinit : palign ( 8 ) {} &gt;&gt; FLASH | FLASH2 .rodata : palign ( 8 ) {} &gt; FLASH | FLASH2 . ARM . exidx : palign ( 8 ) {} &gt;&gt; FLASH | FLASH2 .init_array : palign ( 8 ) {} &gt;&gt; FLASH | FLASH2 .binit : palign ( 8 ) {} &gt; FLASH | FLASH2 . TI . ramfunc : load = FLASH, palign ( 8 ), run=SRAM, table (BINIT) .vtable : &gt; SRAM .args : &gt; SRAM .data : &gt; SRAM .bss : &gt; SRAM .sysmem : &gt; SRAM .stack : &gt; SRAM (HIGH) .BCRConfig : {} &gt; BCR_CONFIG .BSLConfig : {} &gt; BSL_CONFIG } I changed the application Flash starting address to 0x00003800 and modified the .cmd file accordingly: -uinterruptVectors --stack_size= 512 MEMORY { FLASH2 (RX) : origin = 0x00003800 , length = 0x0001C800 SRAM (RWX) : origin = 0x20200000 , length = 0x00008000 BCR_CONFIG (R) : origin = 0x41C00000 , length = 0x00000080 BSL_CONFIG (R) : origin = 0x41C00100 , length = 0x00000080 } SECTIONS { .intvecs: &gt; FLASH2 .text : palign ( 8 ) {} &gt; FLASH2 . const : palign ( 8 ) {} &gt; FLASH2 .cinit : palign ( 8 ) {} &gt; FLASH2 .pinit : palign ( 8 ) {} &gt; FLASH2 .rodata : palign ( 8 ) {} &gt; FLASH2 . ARM . exidx : palign ( 8 ) {} &gt; FLASH2 .init_array : palign ( 8 ) {} &gt; FLASH2 .binit : palign ( 8 ) {} &gt; FLASH2 . TI . ramfunc : load = FLASH2, palign ( 8 ), run=SRAM, table (BINIT) .vtable : &gt; SRAM .args : &gt; SRAM .data : &gt; SRAM .bss : &gt; SRAM .sysmem : &gt; SRAM .stack : &gt; SRAM (HIGH) .BCRConfig : {} &gt; BCR_CONFIG .BSLConfig : {} &gt; BSL_CONFIG } After building the project and attempting to flash it, I received the following error: File Loader: Memory write failed: Flash loader exited with flash error. GEL: File: C:\Users\workspace_ccstheia\bsl_software_invoke_app_demo_can\Debug\bsl_software_invoke_app_demo_can.out: Load failed. Error: (Error -1001 @ 0x0) Requested operation is not supported on this device. (Emulation package 20.5.0.3902) Trouble Halting Target CPU: (Error -2064 @ 0x0) Unable to read device status. Reset the device, and retry the operation. If the error persists, confirm the configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 20.5.0.3902) My requirement is to start the application from 0x00003800 . Could you please let me know how I can achieve this correctly? I have been waiting for your response for quite some time. Could you please provide an update on this issue? Also, I added a function to transmit a CAN message in this project. The project builds successfully without any errors, but I am unable to flash the generated .out file. I get the same flashing error even when using the original .cmd file. Error -1001 @ 0x0: Requested operation is not supported on this device. It is followed by: Error -2064 @ 0x0: Unable to read device status. Could you please help me understand the cause of this issue as well? Regards, Nandinihttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1676985/am6442-am6442b-usb2-hs-bulk-endpoint-scheduler-silent-hang----cadence-cdns3-xhci-host/6488123Fri, 18 Sep 2026 10:43:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d5e96102-a977-40c5-966a-ac27f1dbbff0Tushar ThakurHi, Apologies for the delay here. [quote userid=&quot;174829&quot; url=&quot;~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1676985/am6442-am6442b-usb2-hs-bulk-endpoint-scheduler-silent-hang----cadence-cdns3-xhci-host/6476620&quot;]- Command Ring Abort (CRCR.CA)[/quote] I was referring to command abort operation as mentioned in table 5-24 of xhci specification. Please refer below image. [quote userid=&quot;174829&quot; url=&quot;~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1676985/am6442-am6442b-usb2-hs-bulk-endpoint-scheduler-silent-hang----cadence-cdns3-xhci-host/6476620&quot;]- but note our command ring is healthy (commands complete normally, CMDM_STS0 nominal), so aborting the command ring seems like the wrong tool. Please confirm if you intend this.[/quote] As your endpoint looks stalled, not going to stop state and is in running state. Issuing a command abort should help terminate all the executing commands and stop the endpoint. Also the memory region from where the code is executing, is this marked as cached? If yes, please change the MMU/MPU settings to mark the memory as non-cached or strongly ordered. Regards, Tusharhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1683534/am263p4-questions-regarding-the-keyring-certificateFri, 18 Sep 2026 10:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:43fc9a42-3545-4807-875c-dff1bc1aed93makoto yamashitaPart Number: AM263P4 Is it possible to include a symmetric key in a Keyring certificate? I am asking because the documentation states: &quot;Support for encryption with symmetric auxiliary keys will be added in future releases.&quot; Based on this statement, I would like to confirm whether the current implementation supports storing or distributing symmetric keys through a Keyring certificate. Requested response date: September 25, 2026AM263P4