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/1680850/f29h850tu-i-wrote-the-seccfg-and-i-am-not-able-to-download-anything-anymore-the-downloaded-software-is-running-fine/6485396Wed, 16 Sep 2026 13:37:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:50a14d48-df6f-4245-9832-32fd56dc55ceRonan DANIOUXHello Hu and Zackary, Sorry to come back again on this topic. So, based on the table 9-3, we have to write at these addresses whatever the current bankmode. But the sentence above the table in the TRM says &quot;always program the SECCFG image to the reserve (B2/B3) SECCFG sector address&quot;. The addresses in the table 9-3 are consistent with the (B2/B3) SECCFG sector addresses in the table 9-1 but only for the bankmodes 1, 2 and 3. For the bankmode 0, the addresses for the (B2/B3) SECCFG sector are 0x10D8 5000 for CPU1/2 (compatible with table 9-3) and 0x10D8 D000 for CPU 3 ( not compatible with table 9-3 ). So, there is an inconsistency between the sentence, the content of the table 9-3 and the content of the table 9-1. Where is the truth ? I suppose this will require an update of the document either to correct it or to clarify what looks like an inconsistency. Thank youhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682618/lp-am263p-l2ocram-variables-not-vissible-in-debbuger/6485367Wed, 16 Sep 2026 13:22:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4265aabd-e341-48bf-9104-d3abc792a89fShaunak DeshpandeHi, 1. Are you using a release build with optimization flags? 2. Are you able observe the specific variables in the map file? (ensuring compiler hasnt optimized those out) and are deterministically available in the memory region you desire? Regards, Shaunakhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682777/tms320f28379d-tms320f28379d-launchpad-board-specific-dual-core-boot-hang-in-_system_post_cinit-xcp-external-mode-connect-timeoutWed, 16 Sep 2026 12:53:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:69661015-7fab-4bed-ba20-512fc525ef15yasin shadrouhPart Number: TMS320F28379D Other Parts Discussed in Thread: LAUNCHXL-F28379D , UNIFLASH Subject: TMS320F28379D LaunchPad — Board-specific dual-core boot hang in _system_post_cinit (XCP External Mode connect timeout) Hello, I&#39;m working on a Simulink/Embedded Coder dual-core project (C2000 SoC Blockset, CPU1 + CPU2 + CLA on each core) targeting the TMS320F28379D LaunchPad. On one specific board, the application always fails to establish an External Mode (XCP over Serial) connection after a successful build/flash, while the identical project works correctly on a second, otherwise identical board. Hardware / software: - Board: LAUNCHXL-F28379D, silkscreen &quot;VER: 2.0&quot; - Probe: onboard XDS100v2 - CCS: Theia-based CCS (cloud IDE), emulation package 20.0.0.3283 - MATLAB/Simulink: R2025b, Embedded Coder + C2000 support package - C2000 Device Support Files: tried both 6.23.2.0 and 6.28.3 (updated mid-investigation, no change in behavior) Symptom: After &quot;Build, Deploy &amp; Start&quot; completes successfully (program loads and runs on the target), Simulink External Mode fails to connect: External Mode Open Protocol Connect command failed Caused by: Could not connect to target application: XCP internal error: timeout expired, in response to XCP CONNECT command Isolation steps performed so far: 1. Confirmed the XCP/UART transport layer itself is healthy: a minimal single-task XCP test project connects successfully at both 115200 and 5,000,000 baud, even while CPU2 is independently running. 2. Using CCS debugger (Start Project-less Debug, Connect Target on each core independently and simultaneously), halted execution on both CPU1 and CPU2 while the full application was stuck. In both cases, and across multiple different application builds (including a full dual-core control application and a minimal dual-core &quot;IPC ping-pong counter&quot; project with no ePWM/eCAP/ADC/DAC/CLA content at all), the Program Counter on both cores is consistently parked inside _system_post_cinit() (C runtime startup, before main()) — not inside any application code. 3. Built and ran a genuine single-core-only project (CPU1 only, no CPU2 reference) on the same board — connects and runs without any issue. 4. Performed a full chip erase (UniFlash, both CPU1 and CPU2 flash) and rebuilt/reflashed from scratch — identical hang, ruling out stale or corrupted flash contents. 5. Updated C2000 Device Support Files from 6.23.2.0 to 6.28.3 — no change in behavior. 6. Confirmed the identical project (same .slx files, same build) builds, flashes, and connects correctly on a second F28379D LaunchPad board. Given all of the above, this looks like a board-specific issue affecting only the dual-core boot handshake (both cores appear to independently stall in the same C-runtime startup function, which on this device typically also handles shared-RAM (GSx) ownership arbitration between CPU1 and CPU2), rather than an issue with our application code, XCP configuration, or flash contents. Questions: - Is there a known board-level or silicon-level issue that could cause both cores to independently stall in _system_post_cinit specifically in dual-core configurations (while single-core boots normally)? - Are there specific registers or diagnostics (e.g., related to shared-RAM ownership arbitration, IPC boot flags, or clock/PLL synchronization between cores) we could inspect via the debugger to pinpoint exactly what each core is waiting on? - Could this be related to a marginal/failing component on this specific board that only manifests under the additional load/timing of dual-core bring-up? Happy to provide the .out files, build logs, or a screen recording of the debug session if useful. Thank you for your help.UniFlashLAUNCHXL-F28379DTMS320F28379Dhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682185/f29h850tu-ccs-rtos-object-view-rov-not-displaying-queues-semaphores-mutexes-timers/6485330Wed, 16 Sep 2026 12:41:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3607d09e-c476-4c55-b30a-e5238577e617Pleterski JanThank you for your fast response Arnav. Following your suggestions, here&#39;s what we did and found: 1. configCHECK_FOR_STACK_OVERFLOW — already set to 2 , confirmed via SysConfig. Not the cause. 2. Tested control+rtos_demo example — imported fresh from the same SDK ( f29h85x-sdk_1_02_01_00 ) into our workspace, built and debugged it standalone. Its registered binary semaphore does show up correctly under Mutexes/Semaphores in ROV. This confirms the ROV mechanism and toolchain work in general. 3. Replaced CCS&#39;s installed ROV script — backed up ccs2100/ccs/ccs_base/yarov/rov_freertos.js (the built-in 4-view script: Heap/Stack/TaskModule/TaskInstances — no Queues/Semaphores/Mutexes/Timers at all) and replaced it directly with the SDK&#39;s FreeRTOS.rov.js (7-view version). This removes any ambiguity about which script CCS is actually using. No change — our project&#39;s Queues/Semaphores/Mutexes tabs are still empty. 4. Compared our object registration against the working demo line-by-line: Demo: vQueueAddToRegistry(handle, name); vQueueSetQueueNumber(handle, uniqueValue); — we were missing the vQueueSetQueueNumber() call. We added it (unique non-zero value per object). No change. Timing: we initially assumed our registrations happened after the scheduler started (from task context). We traced our main() and found this is not the case — like the demo, all our registrations happen in main() , before FreeRTOS_init() (which creates tasks and starts the scheduler). So registration timing is equivalent between our project and the demo. Struct layout: verified byte-for-byte via the debugger that our compiled Queue_t layout matches what the ROV script&#39;s manual offset parser expects ( configUSE_QUEUE_SETS=0 in both, no unexpected extra fields). Confirmed via direct memory/register reads that our xQueueRegistry is fully and correctly populated (10/10 valid entries, correct names, ucQueueType=1 for Mutex, non-zero unique uxQueueNumber after our fix). Remaining known difference: the demo registers exactly 1 semaphore; our project registers 4 mutexes. We haven&#39;t been able to test whether object count is the actual trigger, since even a single mutex isn&#39;t showing yet in our project. And our project SDK versions: Best regarding, Janhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682771/ccstudio-theia-unable-to-open-usb-device-when-debug-with-two-controlcardWed, 16 Sep 2026 12:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ee39eacc-06ec-4fce-ab54-f7ff198e76dbBowen LingPart Number: CCSTUDIO-THEIA Hi C2000 team, I set two workspaces for two projects and opened in two CCS windows in one computer. I changed the Serial Number of these projects to specific naming like CC65LV01 and CC65MV01. And when i debug one board fisrt, the code can be downloaded into P650. After this, try to debug another board, it showed LIBUSE_ERROR_ACCESS. Vice versa, swap the sequence is the same result. Do you know where might be the problem? Thanks! BowenCCSTUDIO-THEIAhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682410/tms320f28p650sk-tms320f28p650sk-usb-controller-vid-pid/6485203Wed, 16 Sep 2026 10:07:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:37db446e-ae73-431d-8c22-55033437403eMathieu TrevesHi Siddharth Thank you for your reply. If we do not own a VID, is it allowed to use the ones already set from TI, considering this will be a commerical product sold in the EU? Treves Mathieuhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682410/tms320f28p650sk-tms320f28p650sk-usb-controller-vid-pid/6485107Wed, 16 Sep 2026 08:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8bf4bdf2-d074-4ae4-bc77-5b448590d808Siddharth DeshpandeTreves The USB descriptors (including the VID and PID) are defined in C files, VID and PID are specified in the structure used for Descriptors. For e.g tUSBDBulkDevice g_sBulkDevice = { USB_VID_TI_1CBE, USB_PID_BULK, 500 , USB_CONF_ATTR_SELF_PWR, USBBufferEventCallback, ( void * ) &amp; g_sRxBuffer, USBBufferEventCallback, ( void * ) &amp; g_sTxBuffer, g_ppui8StringDescriptors, NUM_STRING_DESCRIPTORS } ; You can change these IDs . Best Regards Siddharthhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682185/f29h850tu-ccs-rtos-object-view-rov-not-displaying-queues-semaphores-mutexes-timers/6485089Wed, 16 Sep 2026 08:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:50279591-3576-40fc-bf7b-fd3e37892da7Arnav Menon RHello, Thanks for the comprehensive post. One more thing to check would be that the projects SDK version matches the one in which you have the updated ROV file. Also that configCHECK_FOR_STACK_OVERFLOW is set to 2 To verify the ROV file itself, can you check the control+rtos_demo example to see if the semaphore shows up in the ROV. If yes, there may be some problem in the way your registry is set up, and we can debug from there. One stopgap solution I can suggest in case you see no improvements is replacing the CCS installations ROV file directly with the one from the SDK. This file can be found at ccs2100\ccs\ccs_base\yarov\rov_freertos.js (maintain a backup of this as well). For instance, I see the following view for Mutexes when running the freertos_port_validation_tests validation project (There do seem to be mismatches when interpreting mutexes vs semaphores vs queues, but we should at least be able to view all of them) Regards, Arnavhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682277/tms320f28p650dh-max-clock-of-the-clb/6485079Wed, 16 Sep 2026 08:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e40bc549-0072-4ea3-bc4f-d91da787daa8Venkata Praneeth SominaHi Ralf Max clock frequency of CLB tile is 150MHz, Above this frequency, CLB tile logic might not work as intended. Thanks Praneethhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1680850/f29h850tu-i-wrote-the-seccfg-and-i-am-not-able-to-download-anything-anymore-the-downloaded-software-is-running-fine/6485040Wed, 16 Sep 2026 08:00:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:34934a13-463b-40ce-b539-d018a8d86e55Ronan DANIOUXHello Hu, Thank you for your answer. This was the missing piece to have a complete view of how to handle SECCFG. Thank you also Zackary for the previous answers.https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1681898/c2000ware-not-able-to-download-c2000-ware-showing-access-denied/6484943Wed, 16 Sep 2026 06:35:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d6890155-7b85-4191-a286-103761901793Siddharth DeshpandeHi, Pls ensure that your filled up the export approval form correctly. Best Regards Siddharthhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682618/lp-am263p-l2ocram-variables-not-vissible-in-debbugerWed, 16 Sep 2026 06:00:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:48572094-58e7-4ec7-a290-7d64c922195eIonut TidreaPart Number: LP-AM263P Hello, My scope is to use L2OCRAM to place at fixed adresses some variables on a multicore project, in order for each core to access that shared volatile variables. I have configured an MPU region, non chached. ( available on all cores). I have a new linker created which is taken into account by sysCFG linker at build. variables are placed deterministically as such: volatile variable_name NEW_REGION_VAR_SECTION(variable_name); Problem: when putting in watch this variables i receive message: An error occured. But, I can use them (tested with some variables which takes the value of this volatile variables, I can also modified them via code but there are not vissible to the debuger). Can you propose me a solution? Is this the typical behavior?LP-AM263Phttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1680805/tms320f28069-tms320f28069-cannot-connect-flash-jtag-ir-dr-tests-pass-but-c28x-access-fails/6484904Wed, 16 Sep 2026 05:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d2b7d45f-c24c-47b5-ac99-0e96d7cb08e7Pravin KaneThe CSM of Device was locked and I replaced the MCU. Thanks for your Help.https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682416/tms320f28p659sh-q1-why-we-can-t-choose-the-176pin-f28p65sk6-in-sysconfig/6484843Wed, 16 Sep 2026 05:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8934a55a-67f6-4930-84da-ccb86911b884Ira TheteHi, Can you please refer to issue 4 in this FAQ [FAQ] TMS320F28P550SJ: Common Issues Related to SysConfig GUI Thanks, Irahttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1680161/launchxl-f28e12x-technical-support-launchxl-f28e12x-boostxl-drv8323rh---hardware-switches-ccs-v20-x-level-4-inertia-identification/6484807Wed, 16 Sep 2026 04:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:07e862ba-229b-44a6-b551-80258c4fd81bPratik CHHi Peter, If TI planning to add inertia test in future in MotorWareSDK ? and if Yes? When?https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1673584/tms320f28p659sh-q1-an-error-occurs-in-sysctl_setclock-while-reconfiguring-the-clock-after-an-xtal-failure-is-detected-by-dcc/6484791Wed, 16 Sep 2026 03:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:18fa23dc-03a9-476e-a2f8-49fad77e24baPhuong LeI also tested the case where the missing clock is detected using MCD , followed by PLL reconfiguration, and I observed the same behavior. Even after calling SysCtl_resetMCD() , switching the oscillator source to INTOSC1/INTOSC2 using SysCtl_selectOscSource(), and then reconfiguring the clock using SysCtl_setClock() , SYSPLLSTS.LOCKS still remains 0 as long as the XTAL clock is unavailable.https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1673584/tms320f28p659sh-q1-an-error-occurs-in-sysctl_setclock-while-reconfiguring-the-clock-after-an-xtal-failure-is-detected-by-dcc/6484782Wed, 16 Sep 2026 03:36:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:410b653f-e8ff-4816-900b-7a3c30c2df1ePhuong LeHi Aishwarya, Thanks for your suggestion. However, I don&#39;t think the MCD status is the cause in this case. In the DCC-based clock failure detection test, MCD is already disabled by calling SysCtl_disableMCD() . After disabling MCD, I can see that ClkCfgRegs.MCDCR.MCLKSTS remains 0 . I also explicitly called SysCtl_resetMCD() before reconfiguring the clock, but the device still enters ESTOP when SysCtl_setClock() is called. From my debugging, the failure occurs because ClkCfgRegs.SYSPLLSTS.LOCKS remains 0 . As a result, SysCtl_isPLLValid() returns false , causing SysCtl_setClock() to return a failure status and eventually enter ESTOP . At this point, ClkCfgRegs.SYSPLLMULT and ClkCfgRegs.CLKSRCCTL1 already contain the expected values for the INTOSC/PLL configuration, as shown in the screenshot below. However, SYSPLLSTS.LOCKS still does not become 1. One important observation is that, while I keep the clock buffer pins shorted and the XTAL clock remains unavailable, LOCKS stays at 0 . Once I remove the short and the XTAL clock becomes available again , LOCKS changes to 1. This is what I find unclear. I have already switched the oscillator source to INTOSC1/INTOSC2 using SysCtl_selectOscSource() . Therefore, I would expect the PLL to be able to lock using the selected internal oscillator as its clock source, independently of whether the external XTAL clock is still present. Could you please help confirm whether there is any hardware dependency or limitation in the F28P65x PLL/clock circuitry that requires the XTAL clock to be present for the PLL to lock, even after the clock source has been switched to INTOSC1/INTOSC2? Also, could you please confirm whether this behavior is expected from the MCU, or whether it could indicate a hardware issue? Best Regards, Phuonghttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682342/tms320c6726b-tms320c6726b-evm-or-reference-schematic/6484754Wed, 16 Sep 2026 03:01:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ba3ea5e6-5dca-4dae-8856-f056402bf265PaulMI’m checking on this, but the available information is somewhat limited. Also, please be aware that there no longer any design support available. —Paulhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1680850/f29h850tu-i-wrote-the-seccfg-and-i-am-not-able-to-download-anything-anymore-the-downloaded-software-is-running-fine/6484743Wed, 16 Sep 2026 02:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5c96c2a0-6274-4ce0-9a59-fe0c9694b8b6Hu LingHello Ronan, As described in the 9.9.4 chapter in F29x TRM, when you want to update the SECCFG, you need to always operate the update address. The update address depends on the bank mode. For example, if you want to update the CPU1 SECCFG under BANKMODE1, the program/erase address would be the 0x10D99000. And in the Sysconfig, you can configure the bank mode in MEMORY COFIGURATION &gt; Memory Region &gt; Global Patameters &gt; Bank Mode. The generate Seccfg.c will be changed depending on your configuration. Best Regards Hu LINGhttps://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1682540/f29h85x-sdk-tidm-02021Wed, 16 Sep 2026 00:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4f8dcfe2-d924-4c50-976d-f3f878126237anson zhouPart Number: F29H85X-SDK Other Parts Discussed in Thread: TIDM-02021 Hi Sir : Can you provide reference design materials for TIDM-02021, including SCH, PCB, SDK, etc;F29H85X-SDKTIDM-02021