https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/Before making a post please check the <a href="http://processors.wiki.ti.com/index.php/Category:CCS%20">CCS wiki</a> which contains detailed documentation, tutorials and FAQs. en-USTelligent Community 13https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1656425/am335x-tmw-iec61850-demo-best-practices-for-using-vs-code-as-primary-code-editor-with-ccs-compiler-on-windows/6397325Sat, 27 Jun 2026 07:00:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bec8a8b5-f9a9-444f-885c-3ea3430ceb74Zhengzhong LuHi Ki, Thank you so much for the detailed guidance and the helpful link! It is great to know that the new CCS Theia supports using the older compiler from CCS 6.1.3. This approach sounds like a very practical way to modernize the editing experience while minimizing the risks to our existing project. I will review the migration guidelines you shared and do some testing in a separate workspace. Thanks again for your time and expertise! Best regards, Zhengzhonghttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1656425/am335x-tmw-iec61850-demo-best-practices-for-using-vs-code-as-primary-code-editor-with-ccs-compiler-on-windows/6397162Fri, 26 Jun 2026 21:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9f1d1aad-2645-4a12-a34c-5fb9a93269ccKi[quote userid=&quot;531929&quot; url=&quot;~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1656425/am335x-tmw-iec61850-demo-best-practices-for-using-vs-code-as-primary-code-editor-with-ccs-compiler-on-windows/6396433&quot;] if we were to attempt migrating this old CCS 6.1.3 project to the latest version of CCS, are there any potential risks or hidden pitfalls we should be aware of?[/quote] This is a tricky question to answer. It really depends on the dependencies of the project. And as you mentioned in your prior post, some projects and libraries are validated with a certain version of the tools. Hence there is risk to migrate. However there are two things to note that help minimize the migration risk. The first is that older version of the compiler can be used with later CCS versions. CCS 21.0 can use the compilers that came with CCS 6.1.3. It is the compiler version that has the biggest risk. The other thing to note is that the underlying project system remains mostly the same. Of course there have been many enhancements and fixes since 6.1.3, however the project file format and system is mostly the same. [quote userid=&quot;531929&quot; url=&quot;~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1656425/am335x-tmw-iec61850-demo-best-practices-for-using-vs-code-as-primary-code-editor-with-ccs-compiler-on-windows/6396433&quot;]f so, are there any official guidelines or best practices for moving a project from such an old Eclipse-based CCS to the new Theia-based environment without breaking the existing stack?[/quote] There is some information here: https://dev.ti.com/tirex/explore/node?isTheia=false&amp;node=A__AaZFvdACfuKSvvGOsC91Gg__CCSTUDIO-ACADEMY__RdkYJ-M__LATEST You should be able to import the project to CCS Theia and set it up to use the older compiler from CCS 6.1.3.But as you pointed out, 6.1.3 is very old and the gap between versions is quite large. Thanks kihttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1657666/mspm0g1507-ccs-21-0-0-sporadic-error-when-debug/6397150Fri, 26 Jun 2026 20:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:720a7518-9f62-4209-82ba-3262acc766a1KiI received your private message and will continue conversation there. Thanks kihttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1659059/dra821u-q1-custom-jtag-connector-for-xds110-giving-errors/6397131Fri, 26 Jun 2026 20:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2bdf38f6-0f1c-4410-b3f4-0698e99a2725KiHello, [quote userid=&quot;705288&quot; url=&quot;~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1659059/dra821u-q1-custom-jtag-connector-for-xds110-giving-errors&quot;] -----[An error has occurred and this utility has aborted]-------------------- This error is generated by TI&#39;s USCIF driver or utilities. The value is &#39;-233&#39; (0xffffff17). The title is &#39;SC_ERR_PATH_BROKEN&#39;. The JTAG IR and DR scan-paths cannot circulate bits, they may be broken. An attempt to scan the JTAG scan-path has failed. The target&#39;s JTAG scan-path appears to be broken with a stuck-at-ones or stuck-at-zero fault. [/quote] This is a low level JTAG connection failure. The most common cause is hardware issues with the JTAG scan chain: https://software-dl.ti.com/ccs/esd/documents/users_guide_ccs/ccs_troubleshooting-jtag-errors.html#invalid-data-read-back [quote userid=&quot;705288&quot; url=&quot;~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1659059/dra821u-q1-custom-jtag-connector-for-xds110-giving-errors&quot;] I attached an image above showing the current custom adapter wiring from the 10-pin XDS110 connector to the 20-pin EDR JTAG connector. Note that we shorted pins 19 and 20 on the EDR connector. We also tried connecting EDR VREF to XDS110 LPVDD/VTREF and setting the XDS110 reference/supply mode to target/external, but the same errors still occurred. Could someone help confirm whether our custom JTAG mapping looks correct, and any advice you have on how to resolve these errors? [/quote] I will bring this thread to the attention of the device experts to validate your mapping. Thanks kihttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1651942/tms320f28379d-multiple-sampling-per-carrier-frequency-in-epwm/6397041Fri, 26 Jun 2026 19:05:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:06caa1d7-0d6e-4248-a110-f83f0720d38bManish H THi Harisyam, Hope your are doing well. I found the reason behind the subharmonics which were appearing on the scope. It is due to missing of one gating pulse and thus the duty changes and sub harmonics appear. I observed on the oscilloscope that the gating signal is not being generated for a particular carrier cycle by the F28379D Launchpad as seen in the image (the images are the output of the launchpad and not the inverter, I am testing the gate signals before I give to the inverter). And this happens for every sine or modulating cycle at the same instant. I feel this is because of the intersection of carrier with sine wave is happening during update of the sine wave(as seen in the image), and not before or after the update. I have tried this with different cases where I update the sine wave multiple times per carrier wave (let&#39;s say 6 times or 10 times or n times), every time this scenario of intersection between carrier and sine happening during the update of sine wave, there is no gating signal. I have attached my code too, could you please help me with this issue. Use this link for the code that I have used: CLICK HERE TO SEE THE CCS CODE THAT I HAVE USED (I have summarized the code in readme file) (Please use this link if the above isn&#39;t opening: https://drive.google.com/drive/folders/1lKnzDKwUWMQErzT-vis0nendSC3Z1mSA?usp=sharing ) (I have summarized the code in readme file) The below image is a zoomed-in version of what is happening: We can clearly see the intersection is happening between the transition of update of the sine value The below image is a bit zoomed-out version of the same: The below image is to show that it happens every sine cycle at the same instant: Thank you, Warm regards, Manish H Thttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1659059/dra821u-q1-custom-jtag-connector-for-xds110-giving-errorsFri, 26 Jun 2026 17:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3ecd4c72-c5ff-4d0c-a5d1-d0708809f865Bennett YiPart Number: DRA821U-Q1 Other Parts Discussed in Thread: CCSTUDIO , DRA821 , DRA821U Hi, When trying to run the TI Margin Analysis Tool ( Processors DDR Margin Analysis Tool ) to test our board, the tool disconnects and gives this error: xds - disconnected (Error: Failed to connect: Operation was aborted on &#39;DMSC_Cortex_M3_0&#39;) To debug the connection, I also tested the XDS110 connection in CCS/CCStudio. I created a target configuration using: - Connection: Texas Instruments XDS110 USB Debug Probe - Device/board: J7200_DRA821 / DRA821U family I then opened the target configuration in CCS, went to Advanced, and ran “Test Connections.” CCS gave this error: -----[An error has occurred and this utility has aborted]-------------------- This error is generated by TI&#39;s USCIF driver or utilities. The value is &#39;-233&#39; (0xffffff17). The title is &#39;SC_ERR_PATH_BROKEN&#39;. The JTAG IR and DR scan-paths cannot circulate bits, they may be broken. An attempt to scan the JTAG scan-path has failed. The target&#39;s JTAG scan-path appears to be broken with a stuck-at-ones or stuck-at-zero fault. I also tried connecting directly to DMSC_Cortex_M3_0 in CCS and got: &quot;Texas Instruments XDS110 USB Debug Probe/IcePick_M_0 Error connecting to the target: (Error -2131 @ 0x0) Unable to access device register. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 21.0.0.3955)&quot; I attached an image above showing the current custom adapter wiring from the 10-pin XDS110 connector to the 20-pin EDR JTAG connector. Note that we shorted pins 19 and 20 on the EDR connector. We also tried connecting EDR VREF to XDS110 LPVDD/VTREF and setting the XDS110 reference/supply mode to target/external, but the same errors still occurred. Could someone help confirm whether our custom JTAG mapping looks correct, and any advice you have on how to resolve these errors?DRA821CCSTUDIOSoftware-defined vehicleDRA821U-Q1DRA821Uhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1653062/launchxl-f280049c-i2c-code-in-10ms-isr-gives-fifo-timeout-after-changing-some-code-in-250ms-loop/6396713Fri, 26 Jun 2026 14:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:839a4512-f9e9-4ff5-b736-9e376a8acd51Aishwarya RajeshHarihara, I am still not clear if you have tried the debug methods above. As I mentioned already, you have to poll then read like this: I2CsendStartCondition(base); Attempt = 0; while(I2CgetRxFIFOStatus(base) != I2C_FIFO_RX2) // poll FIRST { Attempt++; DEVICE_DELAY_US(200); if(Attempt &gt;= 5) { *I2Cstatus = I2CRxFifoTimout; return 0; } } for(i=0; i&lt;2; i++) tempI2Cdata[i] = I2C_getData(base); // read only after FIFO confirmed ready You only mentioned you commented out the following: If you have already made this change, then make sure you make a similar change when interfacing with TX FIFO, so poll I2CgetStatus() for the I2C_STS_BYTE_SENT flag or equivalent before issuing the repeated start. On every bus timeout/error, you should send a stop condition and reset the I2C module. I already explained this as well, but by modifying the functions you are changing the location of the functions, into a different 128-bit Flash alignment boundary. You can check your flash wait state/other configurations to probably see there are some wait state stalls that the I2C_getData function is being affected by. This is causing timing issues where the function is called BEFORE the I2C RX FIFO is populated. The subsequent while loop then times out because the FIFO is empty. Best Regards, Aishwaryahttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1653062/launchxl-f280049c-i2c-code-in-10ms-isr-gives-fifo-timeout-after-changing-some-code-in-250ms-loop/6396560Fri, 26 Jun 2026 11:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b6248e3d-058d-488a-be41-3b93a85488a9Harihara Kailasa Raman SHi Aishwarya, I have tried and verified the steps you have told us. But how some change in a function in 250ms affects other function in 10ms. Not even a single function is related to both the functions. is this because of reading instructions ? because the function&#39;s address has changed after changing the 250ms ADC function before changing the 250ms function 0008a7b6 _ReadInputPort0 0008a715 _TCAL9539_ReadRegister 0008c07c _GetMuxInput after changing the 250ms function 0008a76c _ReadInputPort0 0008a6cb _TCAL9539_ReadRegister 0008c032 _GetMuxInput these three functions are being called in 10ms for I2C. So in my _TCAL9539_ReadRegister function i gave only 100 microseconds of delay is this because it takes more time to read the instruction so it ends in the stop timeout status of the I2C. Refer to the code i have provided above in my initial post. Thank you.https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1658459/f29h850tu-key-provisioning-using-ti-cybershield-toolkit-fails/6396471Fri, 26 Jun 2026 10:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:060fa826-a459-4a5d-879c-f901abf951d7Aditya SingalHi Marek, Yes, that is an SR10 sample, you are correct. Could you try/confirm a couple of things: After switching to UART Boot Mode, connecting to COM Port and giving a PORSn/XRSn, do you see a hex dump in the serial console? This is to check that the UART connection works fine. After switching to Flash Boot Mode, are you able to connect to the Debugger in CCS using this CCXML file? Thanks and Regards, Aditya Singalhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1656425/am335x-tmw-iec61850-demo-best-practices-for-using-vs-code-as-primary-code-editor-with-ccs-compiler-on-windows/6396433Fri, 26 Jun 2026 09:30:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5cd2304b-8460-4185-bfcd-08e1b998fe96Zhengzhong LuHi Ki, That being said, I am quite curious: if we were to attempt migrating this old CCS 6.1.3 project to the latest version of CCS, are there any potential risks or hidden pitfalls we should be aware of? Given the huge gap between these versions and our dependency on the PROFINET stack, I am concerned about potential compatibility issues regarding the compiler versions, linker command files, or specific project configurations. Would you recommend such a migration? If so, are there any official guidelines or best practices for moving a project from such an old Eclipse-based CCS to the new Theia-based environment without breaking the existing stack? Regards, zhengzhong luhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1657666/mspm0g1507-ccs-21-0-0-sporadic-error-when-debug/6396390Fri, 26 Jun 2026 09:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c69c90cf-5c90-47c8-8438-20b24c637e39Steffen FuchsHi Ki, the project with which we are currently seeing the problem has a main folder with two subfolders which contains the actual projects (ADS/INA). The main folder sits in our workspace besides other projects. We used this constellation with CCS 20.5.1 for weeks without problems. With 21.0.0 we are seeing the mentioned problem but with other projects in the same workspace as well. I will send you the project via PM but I&#180;ve deleted the containing MSPM0 SDK because the upload would be to big. In order to compile please download the latest MSPM0 SDK and unzip it to ADS/MSPM0SDK and INA/MSPM0SDK. Thanks! Best regards Steffenhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1656425/am335x-tmw-iec61850-demo-best-practices-for-using-vs-code-as-primary-code-editor-with-ccs-compiler-on-windows/6396372Fri, 26 Jun 2026 08:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e756849c-23b3-459d-9f8b-6eefad0d3c36Zhengzhong LuHi Ki, Thanks for your detailed reply and the information about the latest CCS versions. The main reason I am still using this older version (CCS 6.1.3) is due to the PROFINET industrial communication protocol stack we are integrating. The code compilation environment and toolchain provided for this protocol stack are specifically tied to this older version of CCS. Upgrading the IDE and compiler would risk breaking the stack&#39;s compatibility or certification, so I am currently forced to continue using it for builds. Because I have to stick with the CCS 6.1.3 toolchain for compilation, I want to use VS Code purely as a modern editor to take advantage of features like IntelliSense and better code navigation. Thanks again for your help! Regards, zhengzhong luhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1643205/mspm0c1105-xds110-holding-reset-pin-ntrst-low-after-flashing-with-uniflash/6396336Fri, 26 Jun 2026 08:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b457a1c1-f5ed-4cf0-9f4b-a3507729faa3Petr GaubeHi Owen, yes you are right the SWCLK is low but only when using LaunchPad XDS110. I did several configuration and tests. All tests are using the same UniFlash configuration, just different HW setup: 1) XDS110 + custom PCB with MSPM0C1105 2) LaunchPad XDS110 + LaunchPad MSMM0C1106 3) XDS110 + LaunchPad MSPM0C1106 4) LaunchPad XDS110 + custom PCB with MSPM0C1105 For each waveform: Green: SWDIO Blue: SWCLK Red: NRST Always start with power up the XDS110. Results: 1) XDS110 + custom PCB with MSPM0C1105 Signals NRST, SWDIO/CLK, VRef (3.3V from target), GND goes from XDS110 into CANON9 over small custom bridge. Only wiring, no pull-ups or something. CANON9 goes directly to needle adapter with PCB. The SWCLK is in low state but only after power up the XDS110, stays at high after first flash. Also here you can see my problem with NRST (stays low after reflash). 2) LaunchPad XDS110 + LaunchPad MSMM0C1106 When trying just the LaunchPad, everything seems to be ok. In my previous post the SWCLK was at high state, no idea what happened. Maybe I used the wrong picture. Sorry about that. 3) XDS110 + LaunchPad MSPM0C1106 Here I used the XDS110 to flash the MSPM0C1106 on the LaunchPad board. The NRST stays at high level which is good. But I have no idea why and what is different between our custom PCB from configuration 1) and your MSPM0C1106 on LaunchPad board. The interesting is that the SWCLK is also in low state only after XDS110 USB powerup. After first flash it stays at high level. 4) LaunchPad XDS110 + custom PCB with MSPM0C1105 Finally I also tried to use LaunchPad XDS110 with our custom PCB. No issue with SWCLK and no issue with NRST! So there is a difference when using XDS110 or LaunchPad XDS110. - the SWCLK is in high state when using XDS110 (black box debug probe) - the NRST stays in low state after reflash only when using XDS110 (black box debug probe) with our custom PCB Again, no special pull-up or pull-down for SWDIO/CLK. For NRST the 47k and 10n used.https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1653062/launchxl-f280049c-i2c-code-in-10ms-isr-gives-fifo-timeout-after-changing-some-code-in-250ms-loop/6395761Thu, 25 Jun 2026 21:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5bc3f3e6-4eeb-447b-9c97-ceae01dd92d9Aishwarya RajeshHarihara, Please complete all the tests mentioned in earlier posts and look into this issue from your end. I have provided all the possible debug steps and issues that could happen from an I2C perspective. At this point, it may just be a general C programming related debug for which I have already provided some clues. Best Regards, Aishwaryahttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1657666/mspm0g1507-ccs-21-0-0-sporadic-error-when-debug/6395580Thu, 25 Jun 2026 18:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:68f2558d-bdfb-4ba8-8892-889a2d558cffKiWould it be possible to provide the project for use to try to reproduce locally? There seems to be an issue with the executable action that is part of the project. Is the project with the executable action also called &quot;ADS&quot; or is that a separate project in your workspace? If it is a separate project, then we&#39;d need both of them.https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1657497/tms320f28377d-ccs-debug-error/6395365Thu, 25 Jun 2026 15:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3eed2024-b5ef-40c1-b60d-65f2b9c40d5cKi[quote userid=&quot;621965&quot; url=&quot;~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1657497/tms320f28377d-ccs-debug-error/6394250&quot;]Please compare your linker command file to the data sheet&#39;s memory map table (Section 7.3.1 C28x Memory Map). If the memory ranges look correct, this may be a CCS related issue.[/quote] In addition to checking the linker command file to the datasheet, also compare it to the debug memory map set in CCS. In general, there are many potential causes for this data verification error. Please see the below article for more details: https://dev.ti.com/tirex/explore/node?isTheia=false&amp;node=A__APy2XbLelxyqBB2Yz0WR.w__ccs_devtools__FUz-xrs__LATESThttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1643205/mspm0c1105-xds110-holding-reset-pin-ntrst-low-after-flashing-with-uniflash/6395146Thu, 25 Jun 2026 13:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:da5f14fb-9b22-47c6-bebf-200b0486ce22Owen LiHi Petr, Yes, I believe there may be an issue with the setup. SWCLK should not be high by default. In the screenshot above, I also probed the SWDIO and SWCLK lines and you can see that the SWDIO line is default high and the SWCLK line is default low. Best, Owenhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1658461/tms320f28379d-sqrt-function-is-taking-more-time-in-executionThu, 25 Jun 2026 08:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:4386e040-2236-426c-ab63-43da7db99caeAkash AhirwarPart Number: TMS320F28379D sqrt function in math.h library is taking 0.5usec. why is taking so long time ? what should be done for less execution time (in ns)? one sqrt func - 2.24us two sqrt func (one by one) - 2.73usTMS320F28379Dhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1658459/f29h850tu-key-provisioning-using-ti-cybershield-toolkit-failsThu, 25 Jun 2026 08:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:5760c494-4277-4f9e-b1aa-c01b839d41d6Marek KowalczykPart Number: F29H850TU Other Parts Discussed in Thread: UNIFLASH , F29H85X-SOM-EVM Hello, I am trying to perform Key Provisioning and Code Provisioning using TI CyberShield Toolkit 26.00.00 STS Release and ti_cst_f29h85x_addon_01_00_00_00. I have a XF29H850TU9T soldered onto a F29H85X-SOM-EVM. Based on the markings &quot;ZEX 3LA-57C7PEW G1&quot; I assume it is a Rev A (SR_10) microcontroller. I also have SDK and TIFS version 26_00_00, CCS 2050 and uniflash 9.5.0 installed. Unfortunately, neither JTAG nor UART approach works. I am trying on both Ubuntu 24 and Windows 10. UART communication fails entirely. JTAG communication occurs only after modyfing the .ccmxl file. JTAG flow allows me to read the device state - as HSFS. I perform the Key Provisioning through JTAG. Provisioning Details window is empty. The Full Log File is as follows: Loading OTP KW binary from: /home/kowalczykm/ti/TICST/addons/f29h85x/bin/otp_kw_f29h85x_hs_fs.hsmimage.bin Loading certificate from: /home/kowalczykm/ti/f29h85x/certificates/final_certificate.bin Writing CMD_CTRL_REG bitmask 0x00000003 to 0x30180508 Loading JTAG flash kernel from: /home/kowalczykm/ti/TI-CyberShield-Toolkit-main/host/bin/asm/f29h85x/secure_ram_based_jtag_kernel.out Expecting target to not halt for 120 seconds Success: we timed out while waiting for the target to halt Log file contents: !!! JTAG FLASH KERNEL LIVE !!! I power reset the device when I&#39;m asked to by the tool and the end result is &quot; Verification Failed. Device is in HSFS state. Expected HSKP or HSSE state after keys provisioning.&quot; This is the console log: (venv) kowalczykm@rze-kowalcmlx-n:~/ti/TI-CyberShield-Toolkit-main$ cstgui Device changed to: F29H85X Setting up F29 development session with data: {&#39;type&#39;: &#39;f29_development&#39;, &#39;smpk_algo&#39;: &#39;rsa4k&#39;, &#39;bmpk_algo&#39;: &#39;rsa4k&#39;} deleting the session Development Creating Development Session Saving Development session... Generate certificate: {&#39;device&#39;: &#39;f29h85x&#39;, &#39;flags&#39;: [&#39;msv_protect&#39;, &#39;s_protect&#39;, &#39;smek_protect&#39;, &#39;b_protect&#39;, &#39;bmek_protect&#39;, &#39;keycnt_protect&#39;, &#39;smpk&#39;, &#39;smek&#39;, &#39;bmpk&#39;, &#39;bmek&#39;], &#39;output_dir_path&#39;: &#39;/home/kowalczykm/ti/f29h85x/certificates&#39;, &#39;pub_key_path&#39;: &#39;/home/kowalczykm/ti/TICST/addons/f29h85x/tifek/SR_10/ti_fek_public.pem&#39;, &#39;msv&#39;: &#39;0x1E22D&#39;, &#39;dev_sr_ver&#39;: &#39;SR_10&#39;, &#39;keycnt&#39;: &#39;2&#39;, &#39;keyrev&#39;: &#39;1&#39;, &#39;sr_sbl&#39;: &#39;1&#39;, &#39;sr_hsmRT&#39;: &#39;1&#39;, &#39;sr_app&#39;: &#39;1&#39;, &#39;sr_ssu&#39;: &#39;1&#39;, &#39;smpk_signing_algorithm&#39;: &#39;rsa4k&#39;, &#39;bmpk_signing_algorithm&#39;: &#39;rsa4k&#39;} Generating certificate with data: {&#39;device&#39;: &#39;f29h85x&#39;, &#39;flags&#39;: [&#39;msv_protect&#39;, &#39;s_protect&#39;, &#39;smek_protect&#39;, &#39;b_protect&#39;, &#39;bmek_protect&#39;, &#39;keycnt_protect&#39;, &#39;smpk&#39;, &#39;smek&#39;, &#39;bmpk&#39;, &#39;bmek&#39;], &#39;output_dir_path&#39;: &#39;/home/kowalczykm/ti/f29h85x/certificates&#39;, &#39;pub_key_path&#39;: &#39;/home/kowalczykm/ti/TICST/addons/f29h85x/tifek/SR_10/ti_fek_public.pem&#39;, &#39;msv&#39;: &#39;0x1E22D&#39;, &#39;dev_sr_ver&#39;: &#39;SR_10&#39;, &#39;keycnt&#39;: &#39;2&#39;, &#39;keyrev&#39;: &#39;1&#39;, &#39;sr_sbl&#39;: &#39;1&#39;, &#39;sr_hsmRT&#39;: &#39;1&#39;, &#39;sr_app&#39;: &#39;1&#39;, &#39;sr_ssu&#39;: &#39;1&#39;, &#39;smpk_signing_algorithm&#39;: &#39;rsa4k&#39;, &#39;bmpk_signing_algorithm&#39;: &#39;rsa4k&#39;} Using development session mode DEBUG: F29 certificate generation command: script_name --device f29h85x --smpk_signing_algorithm rsa4k --bmpk_signing_algorithm rsa4k gencert -t /home/kowalczykm/ti/TICST/addons/f29h85x/tifek/SR_10/ti_fek_public.pem --msv 0x1E22D --msv_protect --bmpk --bmek --b_protect --bmek_protect --smpk --smek --s_protect --smek_protect --sr_sbl 1 --sr_hsmRT 1 --sr_app 1 --sr_ssu 1 --keycnt 2 --keycnt_protect --keyrev 1 -d f29h85x --devSrVer SR_10 -o /home/kowalczykm/ti/f29h85x/certificates DEBUG: Calling f29_main() ----------------------------------------------- F29H85x CyberShield Toolkit CLI ----------------------------------------------- deleting the session Development Creating Development Session Saving Development session... Generating Dual signed certificate!! opening session: Development signing AES key with SigningAlgorithm.PKCS1_V15 signing AES key with SigningAlgorithm.PKCS1_V15 primary cert: signing with SigningAlgorithm.PKCS1_V15 secondary cert: signing with SigningAlgorithm.PKCS1_V15 writing certificates into /home/kowalczykm/ti/f29h85x/certificates Certificate generated successfully DEBUG: F29 certificate generation completed successfully DEBUG: Signing specific F29H85x binaries: [&#39;ram_based_uart_sbl.temp.bin&#39;] DEBUG: F29H85x specific binary signing requested DEBUG: Using session: Development DEBUG: Development session with SMPK: rsa4k, BMPK: rsa4k DEBUG: Using prebuilt images directory: /home/kowalczykm/ti/TI-CyberShield-Toolkit-main/host/bin/asm/f29h85x Signing ram_based_uart_sbl.temp.bin... DEBUG: Signing binary ram_based_uart_sbl.temp.bin with parameters: - Core: C29 - Boot: RAM - KeyRev: 1 - LoadAddr: 0x200E1000 - SwRv: 1 - Debug: DBG_SOC_DEFAULT - CCS Path: /home/kowalczykm/ti/ccs2050 opening session: Development primary cert: signing with SigningAlgorithm.PKCS1_V15 writing signed images into /home/kowalczykm/ti/f29h85x/signedImages Renamed ram_based_uart_sbl.temp.cert.bin → ram_based_uart_sbl.cert.bin Detecting device with boot mode: JTAG, connection info: {&#39;type&#39;: &#39;jtag&#39;, &#39;ccs_path&#39;: &#39;/home/kowalczykm/ti/ccs2050&#39;} 2026-06-25 10:07:49,518 - apps.tifs.kp_cp_f29h85x.jtag_provisioning - INFO - Running Get Device Type command: /home/kowalczykm/ti/ccs2050/ccs/scripting/run.sh /home/kowalczykm/ti/TI-CyberShield-Toolkit-main/host/src/apps/tifs/kp_cp_f29h85x/read_lifecycle.js 2026-06-25 10:07:51,398 - apps.tifs.kp_cp_f29h85x.jtag_provisioning - INFO - Command output: Device is in HS_FS state Device is in HS_FS state 2026-06-25 10:07:51,398 - apps.tifs.kp_cp_f29h85x.jtag_provisioning - INFO - Get Device Type completed successfully DEBUG: Signing binary tifs_f29h85x_hs_se.release.bin with parameters: - Core: HSM - Boot: FLASH - KeyRev: 1 - LoadAddr: 0x00000000 - SwRv: 1 - Debug: DBG_SOC_DEFAULT - CCS Path: /home/kowalczykm/ti/ccs2050 opening session: Development primary cert: signing with SigningAlgorithm.PKCS1_V15 writing signed images into /home/kowalczykm/ti/f29h85x/signedImages DEBUG: Signing binary tifs_f29h85x_hs_se_code_provisioning.release.bin with parameters: - Core: HSM - Boot: RAM - KeyRev: 1 - LoadAddr: 0x00000000 - SwRv: 1 - Debug: DBG_SOC_DEFAULT - CCS Path: /home/kowalczykm/ti/ccs2050 opening session: Development primary cert: signing with SigningAlgorithm.PKCS1_V15 writing signed images into /home/kowalczykm/ti/f29h85x/signedImages DEBUG: Signing binary secure_boot_manager.bin with parameters: - Core: C29 - Boot: FLASH - KeyRev: 1 - LoadAddr: 0x10001000 - SwRv: 1 - CCS Path: /home/kowalczykm/ti/ccs2050 opening session: Development primary cert: signing with SigningAlgorithm.PKCS1_V15 writing signed images into /home/kowalczykm/ti/f29h85x/signedImages DEBUG: Signing binary combined_services_demo.bin with parameters: - Core: C29 - Boot: FLASH - KeyRev: 1 - LoadAddr: 0x10040000 - SwRv: 1 - CCS Path: /home/kowalczykm/ti/ccs2050 opening session: Development primary cert: signing with SigningAlgorithm.PKCS1_V15 writing signed images into /home/kowalczykm/ti/f29h85x/signedImages DEBUG: Signing Sec-Cfg default_seccfg_bankmode_0_ssumode1.out with parameters: - KeyRev: 1 - SwRv: 1 - Boot: FLASH - CCS Path: /home/kowalczykm/ti/ccs2050 Using CCS path: /home/kowalczykm/ti/ccs2050 Created temporary directory: /tmp/tmpfujks8at Extracting CPU1 configuration... Executing: Extracting CPU1 configuration Command: /home/kowalczykm/ti/ccs2050/ccs/tools/compiler/ti-cgt-c29_2.2.0.LTS/bin/c29objcopy -O binary --only-section=.TI.bound:CPU1_Cfg /home/kowalczykm/ti/TICST/addons/f29h85x/bin/default_seccfg_bankmode_0_ssumode1.out /tmp/tmpfujks8at/seccfgCpu1.bin SUCCESS: Extracting CPU1 configuration completed successfully Extracting CPU2 configuration... Executing: Extracting CPU2 configuration Command: /home/kowalczykm/ti/ccs2050/ccs/tools/compiler/ti-cgt-c29_2.2.0.LTS/bin/c29objcopy -O binary --only-section=.TI.bound:CPU2_Cfg /home/kowalczykm/ti/TICST/addons/f29h85x/bin/default_seccfg_bankmode_0_ssumode1.out /tmp/tmpfujks8at/seccfgCpu2.bin SUCCESS: Extracting CPU2 configuration completed successfully Extracting CPU3 configuration... Executing: Extracting CPU3 configuration Command: /home/kowalczykm/ti/ccs2050/ccs/tools/compiler/ti-cgt-c29_2.2.0.LTS/bin/c29objcopy -O binary --only-section=.TI.bound:CPU3_Cfg /home/kowalczykm/ti/TICST/addons/f29h85x/bin/default_seccfg_bankmode_0_ssumode1.out /tmp/tmpfujks8at/seccfgCpu3.bin SUCCESS: Extracting CPU3 configuration completed successfully Checking for CPU configuration files in /tmp/tmpfujks8at Found CPU1 configuration file: /tmp/tmpfujks8at/seccfgCpu1.bin (size: 2048 bytes) Found CPU2 configuration file: /tmp/tmpfujks8at/seccfgCpu2.bin (size: 2048 bytes) Found CPU3 configuration file: /tmp/tmpfujks8at/seccfgCpu3.bin (size: 2048 bytes) Truncating CPU2 configuration file: /tmp/tmpfujks8at/seccfgCpu2.bin Successfully truncated seccfgCpu2.bin from 2048 to 2032 bytes CPU configuration file preparation completed successfully opening session: Development primary cert: signing with SigningAlgorithm.PKCS1_V15 writing certificates into /home/kowalczykm/ti/f29h85x/signedImages Creating output directory: /home/kowalczykm/ti/f29h85x/signedImages Successfully created or verified output directory: /home/kowalczykm/ti/f29h85x/signedImages opening session: Development primary cert: signing with SigningAlgorithm.PKCS1_V15 opening session: Development primary cert: signing with SigningAlgorithm.PKCS1_V15 Creating combined output file: /home/kowalczykm/ti/f29h85x/signedImages/seccfg.bin Successfully wrote combined SecCfg to: /home/kowalczykm/ti/f29h85x/signedImages/seccfg.bin 2026-06-25 10:08:26,732 - apps.tifs.kp_cp_f29h85x.jtag_provisioning - INFO - Running key provisioning with command: /home/kowalczykm/ti/ccs2050/ccs/scripting/run.sh /home/kowalczykm/ti/TI-CyberShield-Toolkit-main/host/src/apps/tifs/kp_cp_f29h85x/run_keyprov_flow.js --otp-kw-bin /home/kowalczykm/ti/TICST/addons/f29h85x/bin/otp_kw_f29h85x_hs_fs.hsmimage.bin --certificate /home/kowalczykm/ti/f29h85x/certificates/final_certificate.bin --jtag-kernel /home/kowalczykm/ti/TI-CyberShield-Toolkit-main/host/bin/asm/f29h85x/secure_ram_based_jtag_kernel.out 2026-06-25 10:09:30,578 - apps.tifs.kp_cp_f29h85x.jtag_provisioning - INFO - Key provisioning completed successfully 2026-06-25 10:09:30,594 - apps.qtgui.utils.log_parser - WARNING - Could not find repository base, using current directory (gnome-text-editor:34470): Gtk-WARNING **: 10:09:37.630: Trying to snapshot GtkGizmo 0x59a8118029b0 without a current allocation (gnome-text-editor:34470): Gtk-WARNING **: 10:09:41.500: Broken accounting of active state for widget 0x59a8129b48e0(GtkPopoverMenu) 2026-06-25 10:10:52,210 - apps.tifs.kp_cp_f29h85x.jtag_provisioning - INFO - Running Get Device Type command: /home/kowalczykm/ti/ccs2050/ccs/scripting/run.sh /home/kowalczykm/ti/TI-CyberShield-Toolkit-main/host/src/apps/tifs/kp_cp_f29h85x/read_lifecycle.js 2026-06-25 10:10:54,060 - apps.tifs.kp_cp_f29h85x.jtag_provisioning - INFO - Command output: Device is in HS_FS state Device is in HS_FS state 2026-06-25 10:10:54,060 - apps.tifs.kp_cp_f29h85x.jtag_provisioning - INFO - Get Device Type completed successfully Contents of my .ccxml: What should I do or change to sucessfully perform Key Provisioning using this tool?F29H850TUUniFlashF29H85X-SOM-EVMhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1643205/mspm0c1105-xds110-holding-reset-pin-ntrst-low-after-flashing-with-uniflash/6394790Thu, 25 Jun 2026 08:06:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:78fa8087-d2d3-4d52-9d6a-b68c6287ec04Petr Gaube... I&#39;m sorry, I accidentally pressed the &quot;This resolved my issue&quot; button. You mentioned that &quot;SWDIO and SWCLK lines are pulled high initially&quot;, but the first waveform is from your LaunchPad without any changes. So, I do not understand why you are saying &quot;SWCLK line should be pulled low&quot;. I just connected the probes to J101 (SWDIO/SWCLK/NRST) while flashing over UniFlash using the LaunchPad as is.