https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1668454/c2000-cgt-cl2000-exe-crashes-with-internal-error/6436603Fri, 31 Jul 2026 22:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6d1ef671-6d92-4399-8434-35425ade3eaeMackay FisherLooking around further I believe this forum thread will resolve your issue: e2e.ti.com/.../debug-assertion-failed-program-c-ti-ccsv5-tools-compiler-msp430_4-1-1-bin-cl430-exe-file-isctype-c-line-68https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1666064/tms320f28075-filtering-multiple-non-consecutive-can-ids-into-a-single-receive-mailbox/6436591Fri, 31 Jul 2026 21:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d8f21789-7a42-4d2e-b86c-ac0fa3d128d4QJ WangHI Michael, You can store multiple messages to one mailbox using ID + Mask. But the DCAN hardware does not support a generic mathematical &quot;modulo-N&quot; calculationhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1668454/c2000-cgt-cl2000-exe-crashes-with-internal-error/6436576Fri, 31 Jul 2026 21:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2f89f8f9-08cb-4f76-ab42-7da6f377121cMackay FisherHi Kosuke, I am having trouble reproducing the issue on my end, to better help you in classifying and investigating the issue can you provide a compiler test case with your failing example. Details on how to do this can be found here: How to Submit a Compiler Test Case . Feel free to reach out if you have any further questions. Thanks and regards, Mackayhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1656202/tms320f28388d-f28388d-nmi-at-boot---flash-uncorrectable-error-in-ti-otp-area-0x070288/6436543Fri, 31 Jul 2026 21:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8deef734-23fb-4f68-81a4-d21be6d1eda2GenatcoHi Steffen, [quote userid=&quot;514504&quot; url=&quot;~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1656202/tms320f28388d-f28388d-nmi-at-boot---flash-uncorrectable-error-in-ti-otp-area-0x070288/6435673&quot;]That rules out an instruction-pointer artifact of the debugger — it&#39;s a content difference in factory-programmed TI OTP that I cannot repair.[/quote] Same basic crazy thing happened our x49c but it was my fault for programming the OTP link pointer bits backwards, MSB-LSB. DCSM would unlock or ignored in CCS debug but not standalone. The MCU bank 0 sector 0-15 was write locked and bank 1 there was just enough sector memory unlocked for the firmware. Odd part is the OTP link pointer bytes seemed offset and even unlocking DCSM code steps shown in TRM did not help. [quote userid=&quot;514504&quot; url=&quot;~/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1656202/tms320f28388d-f28388d-nmi-at-boot---flash-uncorrectable-error-in-ti-otp-area-0x070288/6435673&quot;]0000 1202 0202 1600 0000 D400 0254 0008[/quote] Yea see the OTP link pointer was overwritten by gibberish bytes but you change the link pointer in UniFlash to a new free OTP memory location offset by changing the link pointer. One workaround requires to reconfigure the device.cmd address space to skip over any locked sectors. Perhaps look at Golden OTP link pointers via UniFlash against the failed MCU. The hex link pointers are likely different value between them even by 1 bit can lock reading bank 0 sector 0. As I recall the sector security is disabled in CCS debug or something along that line of thought but not when XDS110 is not connected by design.https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1668796/launchxl-f28p65x-sysconfig-cli-fails-unknown-context-specified-cpu1-for-f28p65x-launchxl-even-using-gui-exported-script-args-cores-in-device-data/6436520Fri, 31 Jul 2026 20:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5a93c597-9f0e-4562-b943-f74cfebe9645KiWould it be possible to share your project and the sysconfig file? Or maybe just the sysconfig file for now. You can send via private E2E message if you wish. Thanks kihttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1661798/tms320f2800154-q1-safety-mechanismn-to-detect-transient-faults-for-cpu1mem_lsx/6436379Fri, 31 Jul 2026 18:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b61ff741-50c4-47f7-ae2a-c155ef2b1486Gus MartinezHi Ben, If the FM report tab you can see that SRAM2 and SRAM16 provide diagnostic coverage to all the failure modes associated with CPU1MEM_LSx.https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1669258/tms320f2800137-when-duty-0-the-pwmb-output-remains-at-a-high-level-all-the-time/6436270Fri, 31 Jul 2026 17:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:99eb940d-44c7-4e45-b502-65cea965e47dSumit Patil1This seems to be correct behavior PWMB is complementary to PWMA so it will stay high. In AHC, EPWMA-AQ signal goes to both rising edge and falling edge (with inversion). In AHC, Rising edge delay is difference between rising edge of A and falling of B. Falling edge delay is difference between falling edge of A and rising edge of B. If you put duty 0 then PWM A will be low completely which brings PWMB high completely. Regards, Sumithttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1669093/f29h850tu-boot-pin-change-without-ssu-config/6436231Fri, 31 Jul 2026 16:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ad0404c0-e1f3-4b3a-b987-a63b4f7bb843Aaron BrutyThank you so much for this very detailed reply, I&#39;ll read this and all the references in detail and get back to you with the results.https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1665750/tms320f28p550sj-can-coff-mode-be-used/6436218Fri, 31 Jul 2026 16:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:82c89582-4cd1-4d33-a10b-62c7a8ffea99Jiaxin TengHi Alfred, Sorry for getting back to you late. Yes, you may try and see if compiling into COFF format works. Have you already tried it? Thanks, Jiaxinhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1668986/tms320f28p550sj-about-of-edge-ai-studio/6436087Fri, 31 Jul 2026 15:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:59b2c764-4b7a-4e10-991e-4f9ce4698bb8W LaiTo select a port and change baud rate, you can follow steps 1 to 4 in https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1479624/edge-ai-studio-can-t-connect-to-the-device-in-the-livepreview/5681144?tisearch=e2e-sitesearch&amp;keymatch=%2520user%253A35028# In particular, if you need to specify a baud rate different than the drop down list of Baud Rate, you can type in the number you need and press Enter to commit that value to the Baud Rate field. After selecting a port and baud rate like in step 3 and above, you proceed &quot; Step 4. Finally, in the Serial Port Configuration dialog, click the OK button.&quot; to connect. If you encounter issues, please let us know.https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1669414/tms320f28p650dh-problem-with-isolated-xds110-debug-probe/6436056Fri, 31 Jul 2026 14:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ec928368-31b7-406d-a21b-01d9cf4f4e42Ralf BartlingHi Peter, yes, I have used the included 16pin male to 14 pin female connector. On my pcb I have a 14 pin male connector which works with the XDS110 without isolation. Best regards Ralfhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1669414/tms320f28p650dh-problem-with-isolated-xds110-debug-probe/6436035Fri, 31 Jul 2026 14:21:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ec2e2c3c-3768-49e0-ac89-382975acc83ePeter LuongHi Ralf, Are you using the correct adapter? The original pinout of XDS110ISO is custom so it wont fit onto typical XDS110 pinout without an adapter Regards, Peterhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1669495/tms320f28335-cbc-behaviour-in-epwm-up-down-count-modeFri, 31 Jul 2026 13:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:203e4008-5b7c-4ed4-8103-dfb2033d717eGonzalo SanchezPart Number: TMS320F28335 Dear community, We have some doubts about the trip-zone force cycle-by-cycle behaviour in UP-DOWN count mode. As far as we understand, after setting the TZFRC.CBC bit by software, the only condition that should restart the ePWM outputs is when the counter reaches zero (TBCTR = 0). In up-down count mode, this condition is met only every 2xTBPRD ( two periods). The thing is, the ePWM modulus seems to be retriggering not only when TBCTR = 0 but also when TBCTR = TBPRD. &#191;Does it make any sense? We have observed this behaviour on the oscilloscope. TZ init (same for empw 2 and 3) // Enable TZ1 as one shot trip sources EPwm1Regs.TZSEL.bit.OSHT1 = TZ_ENABLE; // What do we want the TZ1 to do? EPwm1Regs.TZCTL.bit.TZA = TZ_FORCE_LO; EPwm1Regs.TZCTL.bit.TZB = TZ_FORCE_LO; // Enable TZ interrupt EPwm1Regs.TZEINT.bit.OST = TZ_DISABLE; EPwm1Regs.TZEINT.bit.CBC = TZ_DISABLE; ePWM init (same for empw 2 and 3) EPwm1Regs.TBCTL.bit.HSPCLKDIV = TB_DIV1;//TB_DIV2; EPwm1Regs.TBCTL.bit.CLKDIV = TB_DIV1; EPwm1Regs.TBPRD = PWMRED; EPwm1Regs.TBCTR = 0x0000; EPwm1Regs.TBPHS.half.TBPHS = 0x0000; EPwm1Regs.TBCTL.bit.CTRMODE = TB_COUNT_UPDOWN;// Symmetrical mode EPwm1Regs.TBCTL.bit.PHSEN = TB_DISABLE; EPwm1Regs.TBCTL.bit.PRDLD = TB_SHADOW; EPwm1Regs.TBCTL.bit.SYNCOSEL = TB_CTR_ZERO; EPwm1Regs.CMPCTL.bit.SHDWAMODE = CC_SHADOW; EPwm1Regs.CMPCTL.bit.SHDWBMODE = CC_IMMEDIATE; EPwm1Regs.CMPCTL.bit.LOADAMODE = CC_CTR_ZERO_PRD; // load on CTR=Zero EPwm1Regs.CMPCTL.bit.LOADBMODE = CC_CTR_ZERO_PRD; // load on CTR=Zero EPwm1Regs.AQCTLA.bit.CAU = AQ_CLEAR; // set actions for EPWM1A EPwm1Regs.AQCTLA.bit.CAD = AQ_SET; EPwm1Regs.AQCTLB.bit.CAU = AQ_SET; // set actions for EPWM1A EPwm1Regs.AQCTLB.bit.CAD = AQ_CLEAR; EPwm1Regs.DBCTL.bit.OUT_MODE = DB_FULL_ENABLE; // enable Dead-band module EPwm1Regs.DBCTL.bit.POLSEL = DB_ACTV_HIC; // Active Hi complementary EPwm1Regs.DBFED = PWM_DEADBAND_CNT; EPwm1Regs.DBRED = PWM_DEADBAND_CNT; CBC bit setting EALLOW; EPwm1Regs.TZFRC.bit.CBC = 1; EPwm2Regs.TZFRC.bit.CBC = 1; EPwm3Regs.TZFRC.bit.CBC = 1; EDIS; We are setting the CBC bits on the GPIO ISR (gpio_xint1_isr) when an external condition is detected on the PIN (falling edge) and in the main loop if the condition persists (PIN low).Energy infrastructureTMS320F28335https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1666672/tms320f28p659dk-q1-more-than-two-fast-observers-running-at-the-same-time/6435980Fri, 31 Jul 2026 13:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:254eb28d-7540-42ff-880b-0e9f35c186e9Yanming LuoNo. The current FAST library only supports up to two motors, that needs to another specific FAST library for support 3 or more motors.https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1669482/f29h850tu-what-are-sdk-examples-that-simulate-max-power-consumption-in-the-deviceFri, 31 Jul 2026 12:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bc53f3f2-e8ad-4ae7-bf58-ddc3f1c25100Lenio CaculaPart Number: F29H850TU My customer needs to verify the design of their power supply. What is (are) code example(s) that either alone or combined would allow a max current consumption experiment? Thank you!F29H850TUIndustrial Automationhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1669461/tms320f28384s-tms320f28384s-emif2-connect-issueFri, 31 Jul 2026 11:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c875233e-2c46-47f1-849d-65d39906145dAllen ChuPart Number: TMS320F28384S Dear Engineer, Is it feasible to use the emif2 module of TMS320F28384S, with data pins D0~D15 connected to both the SDRAM chip and ADS8588, to simultaneously read and write data from both the SDRAM chip and ADS8588 chip through CS0n and CS2n chip selection?TMS320F28384Shttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1667948/tms320f28p650dk-cli-toolchain-creation-on-ubuntu/6435851Fri, 31 Jul 2026 10:32:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6d2fffa1-07b0-4c0a-94d8-21fefe447e9bIra TheteHi Parthiv, Can you try the following run &quot;export TI_SDK_PATH =/path/to/c2000ware # adjust path as needed&quot; Or edit the CLI config file (~/.ti/sysconfig/config.json) to include { &quot;sdkPath&quot; : &quot; /path/to/c2000ware &quot; } Verify the registration by listing supported devices: ti sysconfig --list-devices | grep F28P65x If the device appears, the CLI is correctly linked to the SDK. If you still see the “Invalid argument &#39;--product&#39;” error after these steps, double‑check that the TI_SDK_PATH points to the exact root folder of the C2000Ware installation and that the version directory matches the required. Thanks, Irahttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1669414/tms320f28p650dh-problem-with-isolated-xds110-debug-probeFri, 31 Jul 2026 09:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a8215f19-6cf1-4e21-a462-20b00976736eRalf BartlingPart Number: TMS320F28P650DH Hello, I&#180;m working with CCS12.6 and a the standard XDS110 emulator probe and I want to switch to the isolated XDS110 probe. The probe is correctly installed but after start of the debugger I got the following message: What is the reason for this problem? Thank you very much RalfTMS320F28P650DHEnergy infrastructurehttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1669043/tms320f280039c-f280039c-hrpwm-can-cmpahr-and-cmpbhr-independently-control-two-epwmxa-edges/6435761Fri, 31 Jul 2026 08:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1814522d-1360-4e2e-9e65-89b569384814Venkata Praneeth SominaHi, CMPAHR is for use with Action Qualifier output of Channel A, and CMPBHR is for use with the Action Qualifier output of Channel B. They operate on separate output channels, not two edges of the same output. If high resolution control on both edges is needed, BE mode with TBPHSHR need to be used. CMPAHR/CMPBHR would not be used here. Thanks Praneethhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1656202/tms320f28388d-f28388d-nmi-at-boot---flash-uncorrectable-error-in-ti-otp-area-0x070288/6435673Fri, 31 Jul 2026 07:51:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:1389d028-6c07-4322-b2d2-607c1932c7baSteffen FreiHi Genatco, thank you for the hint. I set up a very simple LED blinky example (CPU1_FLASH configuration, no application code, no optimization) and tested it. Unfortunately this did not work either — the device still fails before reaching user code. It never gets to _c_int00 / main ; it is already stuck in the Boot ROM NMI handler at that point. That&#39;s a helpful angle, and I looked into it — but I think this case is a bit different from the LAUNCHXL-49C one. The code that fails here isn&#39;t compiled C/C++ from my project; it&#39;s the factory Device_cal routine in TI OTP (entry point 0x070260), which the Boot ROM calls during its own initialization, before any user code runs. So optimization level and FUNCTION_OPTIONS only affect my source, which never gets that far. Device_cal is fixed silicon content, identical on every unit. There&#39;s one more data point that confirms this: even in a normal debug session that otherwise runs fine, as soon as I call the calibration routine from user code via the HAL wrapper Device_cal() (which is just a direct call to 0x070260), I get the exact same NMI with the same FLUNCERR and the same latched addresses. So the fault reproduces regardless of how execution reaches that OTP location — Boot ROM or user code. You&#39;re also right that the debug disassembler&#39;s instruction pointer can be misleading, so I didn&#39;t rely on single-stepping. Instead, thanks to a former colleague, I obtained a raw memory readout of 0x070260–0x0702B4 from a confirmed-working F28388D (the reference dump I had been asking for) and compared it word-for-word against the failing device. Raw memory contents (16-bit words): GOLDEN (working device): 0x070260 7700 7700 7608 7622 8D85 D33C 8EC2 1AC2 000F 8D87 01BC 8DC5 D736 28A4 0003 9282 9B00 0x070271 1E83 000C FFFD 8D87 015C 8DC0 743B 28A4 0003 8582 3E00 00FF 9683 DB7F 000C FFFB 8D87 0x070282 0128 8DC0 7470 28A4 0003 28A5 0005 9282 9382 1E83 000D FFFD DB74 000C FFF8 761F 174C 0x070293 3A3C 8D85 D342 8EC2 1ACA 0007 8D87 0160 8DC0 5C06 28A4 0002 8582 9683 DB0F 000C FFFD 0x0702A4 761F 174D 3A02 7600 0006 28A0 0010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FAILING device: 0x070260 7700 7700 7608 7622 8D85 D33C 8EC2 1AC2 000F 8D87 01BC 8DC5 D736 28A4 0003 9282 9B00 0x070271 1E83 000C FFFD 8D87 015C 8DC0 743B 28A4 0003 8582 3E00 00FF 9683 DB7F 000C FFFB 8D87 0x070282 0128 8DC0 7470 28A4 0003 28A5 0000 1202 0202 1600 0000 D400 0254 0008 FFF8 761F 174C 0x070293 3A3C 8D85 D342 8EC2 1ACA 0007 8D87 0160 8DC0 5C06 28A4 0002 8582 9683 DB0F 000C FFFD 0x0702A4 761F 174D 3A02 7600 0006 28A0 0010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF The two dumps are bit-for-bit identical except for exactly eight consecutive words, 0x070288–0x07028F: ADDR GOLDEN FAILING ----------------------------- 0x070288 0005 0000 0x070289 9282 1202 0x07028A 9382 0202 0x07028B 1E83 1600 0x07028C 000D 0000 0x07028D FFFD D400 0x07028E DB74 0254 0x07028F 000C 0008 These eight words are precisely the two 64-bit ECC blocks flagged by the flash ECC logic: Block @0x070288 GOLDEN: 0005 9282 9382 1E83 FAILING: 0000 1202 0202 1600 Block @0x07028C GOLDEN: 000D FFFD DB74 000C FAILING: 0000 D400 0254 0008 which match UNC_ERR_ADDR_LOW = 0x070288 and UNC_ERR_ADDR_HIGH = 0x07028C exactly. The corruption starts and ends precisely on the ECC block boundaries; everything before 0x070288 and from 0x070290 onwards is identical. Disassembled, the difference is easy to interpret. On the working device these two blocks form a third register-copy loop, structurally parallel to the two loops before it: ADDR GOLDEN (working) FAILING DEVICE -------------------------------------------------------------------------------------------- 0x070285 = 28A40003 MOV @AR4, #0x0003 | 28A40003 MOV @AR4, #0x0003 0x070287 &#187; 28A50005 MOV @AR5, #0x0005 | 28A50000 MOV @AR5, #0x0000 0x070289 &#187; 9282 MOV AL, *XAR2++ | 1202 MPY ACC, T, @0x2 0x07028A &#187; 9382 MOV AH, *XAR2++ | 0202 MOVB ACC, #2 0x07028B &#187; 1E83 MOVL *XAR3++, ACC | 1600 MOVP T, @0x0 0x07028C &#187; 000DFFFD BANZ -3,AR5-- | 0000 ITRAP0 &lt;-- trap occurs here 0x07028E &#187; DB74 ADDB XAR3, #116 | D400 MOVB XAR4, #0x0 0x07028F &#187; (cont.) | 0254 MOVB ACC, #84 0x07028F = 000CFFF8 BANZ -8,AR4-- | 0008FFF8 BANZ -8,AR0-- 0x070291 = 761F174C MOVW DP, #0x174c | 761F174C MOVW DP, #0x174c On the failing device the loop counter is flipped from 5 to 0 and both blocks decode into incoherent instructions, so the decoder desynchronizes and hits 0x0000 (ITRAP0) at 0x07028C. So two independent mechanisms point at exactly the same physical words: the instruction decoder (ITRAP) and the flash ECC logic (latched addresses 0x070288 / 0x07028C). That rules out an instruction-pointer artifact of the debugger — it&#39;s a content difference in factory-programmed TI OTP that I cannot repair. I&#39;ll consider this root cause confirmed. I won&#39;t go through the formal return process — the DSP itself is inexpensive, so an RMA isn&#39;t worth the effort on my end. Reworking the part isn&#39;t practical either: it&#39;s a 337-ball BGA, and we don&#39;t have the capabilities to reliably desolder and replace it in-house, so recovering from this effectively means populating an entire new control board from scratch. That&#39;s what makes this unfortunate — while the DSP itself is cheap, the real cost of the failure is a multiple of that on a hand-populated one-off. If it&#39;s useful for TI&#39;s own tracking or failure analysis, I&#39;m happy to share the lot/date code and the full register/dump set. Thanks both for the help — Genatco, the pointer to the emulation/standalone speed difference was a good thing to check; it just turned out the fault sits below the application layer here. Greetings, Steffen