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/1686782/mspm33-sdk-sizeof-for-structure-and-alignment/6502961Tue, 06 Oct 2026 16:03:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bf56c2e6-c523-40b2-91b7-d52aa5113711Todd SniderHi Sebastien, The compiler behavior should work as follows: The alignment constraint associated with the MainStructure is the maximum alignment imposed by each of the MainStructure members If the MainStructure alignment constraint, x, is &gt;= y in palign(y), then the address where MainStructure is defined will be aligned to a x-byte boundary, note that the size of the section in which MainStructure is defined will be padded to a multiple of y-bytes due to the palign(y) If the MainStructure alignment constraint, x, is struct { char c1; short s2; int i3; float f4; double d5; short s6; char c7; } MainStruct = { 10, 20, 30, 40.5, 50.125, 60, 70 }; int main() { printf(&quot;MainStruct.c7: %d\n&quot;, (int)MainStruct.c7); return 0; } When this is compiled with &quot;tiarmclang -mcpu=cortex-m33 -S tryme.c,&quot; the relevant compiler generated assembly looks like this: .section .text.main,&quot;ax&quot;,%progbits .globl main .p2align 1 .code 16 .thumb_func main: push {r7, lr} sub sp, #8 movs r0, #0 str r0, [sp] str r0, [sp, #4] movw r0, :lower16:MainStruct movt r0, :upper16:MainStruct ldrb r1, [r0, #26] movw r0, :lower16:.L.str movt r0, :upper16:.L.str bl printf ldr r0, [sp] @ 4-byte Reload add sp, #8 pop {r7, pc} ... .section .data.MainStruct,&quot;aw&quot;,%progbits .globl MainStruct .p2align 3, 0x0 MainStruct: .byte 10 @ 0xa .byte 0 @ 0x0 S_MEM ... } S_MEM starts on an unaligned address. The palign(16) will force the definition of &quot;MainStruct&quot; to start on a 16-byte boundary even though the minimum alignment requirement for the struct is on an 8-byte boundary. Furthermore, the size of the .mainStruct section will be padded to a multiple of 16 bytes. This is reflected in the content of the map file: .mainStruct * 0 20200010 00000020 UNINITIALIZED 20200010 00000020 tryme.o (.data.MainStruct) If you want to avoid the padding caused by the palign(x) operator, you can use the align(x) operator instead. Hope this helps. Please reply if you have further questions or need further clarification. Best Regards, Todd Sniderhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684114/am3358-ccs-12-working-with-jtag-probe-xds200-to-trace-u-boot-and-vmlinux-based-on-am335-sdk/6502751Tue, 06 Oct 2026 12:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7cfd2a1d-b600-427d-ad2b-cca4621c772eKaloyan DimitrovHi Vinu, I have pasted the wrong link in the opening of my question here is a bit more detailed and double checked info about the CCS and the SDK that I am using: SDK: Download URL: https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-1BUptXj3op/11.02.05.02/ti-processor-sdk-linux-am335x-evm-11.02.05.02-Linux-x86-Install.bin SHA verification of the binary: ~/Downloads$ sha256sum ti-processor-sdk-linux-am335x-evm-11.02.05.02-Linux-x86-Install.bin db66123e08c4ff2d7d262e8ae8001fe69761d6779071fbcd950fc6246c53ce10 ti-processor-sdk-linux-am335x-evm-11.02.05.02-Linux-x86-Install.bin MD5 fingerprint of the manifest directory in the already installed on the system SDK: ~/ti-processor-sdk-linux-am335x-evm-11.02.05.02$ md5sum manifest/* 834085e14870dfd6e6f1c604643222d8 manifest/software_manifest.htm c85526567390816c9e53505c6147c719 manifest/software_manifest.txt CCS I have already posted screenshots of the CCS U-boot project of the SDK you can reverify by that, too. Thanks, Kalhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684114/am3358-ccs-12-working-with-jtag-probe-xds200-to-trace-u-boot-and-vmlinux-based-on-am335-sdk/6502602Tue, 06 Oct 2026 09:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ed09e94f-a673-497d-9cfe-d405cec7530aVinuchandran A VHi Kal, Can you please confirm the SDK and CCS versions you are using right now? The link you&#39;ve shared is for SDK 02.00.02.11, which is released in 2016, but the logs show logs from Uboot 2025.11. Regards, Vinuhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1686782/mspm33-sdk-sizeof-for-structure-and-alignment/6502562Tue, 06 Oct 2026 08:42:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9fce16af-15d1-42bd-bac7-ff7df7b1453cSebastien Le DiourisHello Arthur, ok for that but why the compiler added paddings if it is aligned at 16bits ? If it was a 8 bits, I understood. How avoid to add padding, and the data are stored address by address ?https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684114/am3358-ccs-12-working-with-jtag-probe-xds200-to-trace-u-boot-and-vmlinux-based-on-am335-sdk/6502085Mon, 05 Oct 2026 20:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:cda55fb3-14f0-4a3d-88a2-35736d3b1c94Kaloyan DimitrovHi Tushar, Thanks for the links, I did look into all the discussed issues and did some testing on my own nothing out of the topics discussed solved my two issues discussed above: CCS terminating when an attempt is done on loading the vmlinux for JTAG tracing Not being able to run u-boot with JTAG for hitting HW breakpoints, basically staying in the infinite loop in the ti-u-boot-2025.01~/lib/hang.c which terminates after a certain amount of time but I am not able to start executing the u-boot.bin even though I am able to load the application and symbols for it using CCS, on the console I see only this as mentioned above: U-Boot SPL 2025.01-ga44465cad8a3 (Sep 17 2026 - 17:14:14 -0400) SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### Control stays with the JTAG probe - one cannot get hold of the console - hitting Enter etc. doesn&#39;t produce any result till the moment when I presume that some timeout happens and the normal boot procedure kicks in and the XDS200 probe relinquished control and if the system is setup properly MLO, u-boot and kernel execute and the evaluation board boots into a root filesystem. But some new information and a bit more understanding about how the JTAG probe should be setup and used was reached in the process. The new info is the following: Target Configuration: Used *.ccxml file FILE: BBB-XDS200.ccxml e2e.ti.com/.../Configuration_5F00_File_2D00_ccxml.txt My question related to that are: if I want to run the Linux kernel and HW break its execution do I need the initialization scripts in the Advanced Target configuration( *.gel files) or those need to be removed for the target configuration? Is there a difference when one traces an application running on embedded Linux board vs kernel booting ? I also looked into the proposed fix for an older kernel 3.x in the static struct omap_hwmod am33xx_debugss_hwmod adding flags in the default configuration - .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET) my current kernel code is being tested with this values: ~/ti-processor-sdk-linux-am335x-evm-11.02.05.02/board-support/ti-linux-kernel-6.12.49+git-ti/arch/arm (ti-linux-6.12.y)$ vim +123 ./mach-omap2/omap_hwmod_3xxx_data.c /* debugss */ static struct omap_hwmod omap3xxx_debugss_hwmod = { .name = &quot;debugss&quot;, .class = &amp;omap3xxx_debugss_hwmod_class, .clkdm_name = &quot;emu_clkdm&quot;, .main_clk = &quot;emu_src_ck&quot;, .flags = HWMOD_NO_IDLEST, }; I am getting error unable to access the DAP on a really rare occasions, so I don&#39;t think that is the issue that I am facing but still follow-up and clarification on is the proper file for corrections with the current SDK is ./mach-omap2/omap_hwmod_3xxx_data.c and the correct structure is static struct omap_hwmod omap3xxx_debugss_hwmod is worth confirming also potential up-to-date values for the .flags variable if they are different for the ones described in the thread discussing the issue. And finally some Errors and notifications that I keep hitting and I don&#39;t know how to exactly follow on and resolve - visible in the Console window in the screenshots provided below: U-boot_AutoRun-Target not run as the symbol main is not defined-Paused vs Running: Kernel_Loader-One or more sections of your program falls into a memory region that is not writable: I will provide more details on other tests that I have performed but my three questions above are the ones that seem to me the most important ones that need to be addressed for the time being. Please, do not hesitate to follow up is more info is needed on my end or my explanations are ether not detailed enough or not obvious enough. Thanks, Kalhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1686782/mspm33-sdk-sizeof-for-structure-and-alignment/6501705Mon, 05 Oct 2026 15:14:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e6603776-0d54-4b09-8d95-3ef25df58508JOJO ARTHURHello Sebastian, The behavior you are observing is expected and caused by compiler structure padding/alignment rather than the linker palign() setting. In C, the compiler may insert padding bytes between structure members so that each member starts at an address satisfying its alignment requirement. For example, if a uint16_t is followed by a structure requiring 4-byte alignment, two padding bytes may be inserted after the uint16_t. This can then cause the size of MainStructure to be larger. When 16 is replaced by 32, no padding is necessary hence the right size will be observed. Regards, Benedict Jojohttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1681922/tms320f28377d-ccs-build-report/6501451Mon, 05 Oct 2026 09:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:609aa951-12c6-495d-82f1-81073d466dd7Ira TheteHello, Please follow the below steps to generate build logs in CCS 20.2 1. Go to project -&gt; properties -&gt; build -&gt; build_output log file Create a .txt file to dump your build log in. One you do this; the build log will get written to this file Thanks, Irahttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1686782/mspm33-sdk-sizeof-for-structure-and-alignmentFri, 02 Oct 2026 11:59:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c8c3cfa9-e52c-4208-a77b-fff7a9b629e4Sebastien Le DiourisPart Number: MSPM33-SDK Other Parts Discussed in Thread: MSPM33C321A Hello, I&#39;m working on MSPM33C321A on CCS, I have declared a structure where inside there are other structures, like this: typedef struct { sStructure1 S_struct1; uint16_t u16Data1; sStructure2 S_struct2; sStructure3 S_struct3; sStructure4 S_struct4; sStructure5 S_struct5; sStructure6 S_struct6; sStructure7 S_struct7; uint16_t u16Data2; }MainStructure; I check that: sizeof(MainStructure) is not equal to sizeof (sStructure1) + sizeof(u16Data1) + sizeof (sStructure2) + sizeof (sStructure3) + .... + sizeof (sStructure7) + sizeof(u16Data2) But if the int16_t are moved by uint32_t, I have : sizeof(MainStructure) = sizeof (sStructure1) + sizeof(u32Data1) + sizeof (sStructure2) + sizeof (sStructure3) + .... + sizeof (sStructure7) + sizeof(u32Data2) I checked in linker file, and the alignment are declare on 16 bits Could you tell me if it possible to fix this issue ? ThanksMSPM33C321AMSPM33-SDKhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1686338/tms570ls1227-segger-j-link-usage-with-cortex-r/6499166Thu, 01 Oct 2026 04:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:e5ce1eef-38bd-41c1-b168-41a24f57445ejagadish gundavarapuHi Jacob, I never came across this issue before, on first level could you please verify below of our internal AI suggestions: Issue 1: &quot;Break at Address 0x0&quot; on Connect This is almost always caused by one of the following: Root Cause A: ECC Initialization Conflict The TMS570LS1227 runs a hardware ECC initialization routine in ROM before reaching your code. The J-Link interrupts this and lands at 0x0. Fix - Verify your JLinkScript is actually being loaded: // In CCS Debug Configuration: // Target &gt; J-Link &gt; JLinkScript file field // Confirm the FULL absolute path is specified, not relative // e.g., C:/JLink/Scripts/TI_TMS570Lx_SkipECCInit.JLinkScript Check the J-Link log output in CCS console for: Script: Found and executed If you do NOT see this, the script is silently failing to load. Root Cause B: Reset Handling Misconfiguration In your CCS Debug Configuration, verify these settings under Target &gt; Reset Configuration : Setting Recommended Value Reset Type Core Reset (not System Reset) Reset at connect Disabled initially for live debug Halt after reset Disabled for connect-to-running Issue 2: Endianness Mismatch Error When Using JLinkScript This is the key issue and is likely masking everything else. What&#39;s Actually Happening The TMS570LS1227 is a big-endian Cortex-R4F. The J-Link drivers sometimes misidentify endianness when a JLinkScript modifies the connection sequence. Verify your .ccxml target configuration: JLinkScript Endianness Declaration The provided SEGGER script may be missing or have an incorrect endianness declaration. Open TI_TMS570Lx_SkipECCInit.JLinkScript and verify/add: // At the top of the JLinkScript file int InitTarget( void ) { // Explicitly declare big-endian JLINK_ExecCommand( &quot;SetEndian big&quot; ); // ... rest of ECC skip code return 0 ; } If the script does not contain this, add it as the first line of InitTarget() . Issue 3: Cannot Read Memory/Variables Without Halting This is a real-time memory access limitation with the J-Link on TMS570. Enable DAP-Based Non-Intrusive Access In CCS Debug Configuration under J-Link settings: Enable &quot;Non-intrusive (SWO/SWV)&quot; → Disabled (TMS570 doesn&#39;t support SWO) Enable &quot;Allow memory access during run&quot; → Check if available Alternative: Use ARMV7 DAP Directly In your .ccxml , try forcing the connection through DAP: Note: The TMS570LS1227 does NOT support true run-time memory access without the ETM/ETB infrastructure being configured. This is a silicon limitation, not a J-Link limitation. The XDS100V2 had the same restriction but handled it differently through TI&#39;s proprietary ICEPICK router. Issue 4: CCS Package Manager Failure / Manual DLL Replacement This is likely the root cause of several downstream issues . Proper Manual Integration Steps Rather than replacing the DLL directly (which causes version conflicts), do the following: Step 1: Install J-Link software from SEGGER separately Step 2: In CCS, go to: Window &gt; Preferences &gt; Code Composer Studio &gt; Debug &gt; GDB SEGGER J-Link Debugging Step 3: Point CCS to the installed J-Link directory explicitly: C:/Program Files/SEGGER/JLink_V798/ Step 4: Do NOT mix DLLs between CCS internal versions and SEGGER installed versions. Remove any manually placed DLLs from: [CCS Install]/ccs/ccs_base/DebugServer/drivers/ Recommended Complete Debug Configuration Connection: SEGGER J-Link Device: TMS570LS1227ZWT ← Verify exact part suffix Interface: JTAG Interface Speed: 1000 kHz (start low, increase after stable) JLinkScript: [full path]/TI_TMS570Lx_SkipECCInit.JLinkScript Reset: Core Reset Halt on connect: NO (for connect-to-running) Recommended Troubleshooting Sequence 1. Remove all manually placed DLLs from CCS directories 2. Reinstall J-Link V7.98 cleanly from SEGGER 3. Point CCS Preferences to the SEGGER install directory 4. Create a fresh .ccxml using CCS Target Configuration editor 5. Add SetEndian big to JLinkScript InitTarget() 6. Set Interface Speed to 1000 kHz 7. Disable all reset-on-connect options 8. Connect and check J-Link log for script execution confirmation If All Else Fails: J-Link GDB Server Approach Bypass CCS&#39;s J-Link integration entirely: # Launch J-Link GDB Server manually JLinkGDBServer.exe -device TMS570LS1227 -endian big \ -if JTAG -speed 1000 -scriptfile TI_TMS570Lx_SkipECCInit.JLinkScript # Then connect CCS to localhost:2331 via GDB This isolates whether the issue is CCS integration or the J-Link connection itself. -- Thanks &amp; regards, Jagadish.https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1686338/tms570ls1227-segger-j-link-usage-with-cortex-rWed, 30 Sep 2026 20:20:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8a0830c2-2c92-4fe8-b45a-7759f09aa04cJacob ByersPart Number: TMS570LS1227 Other Parts Discussed in Thread: CCSTUDIO Hello, I am shifting from the XDS100V2 to the Segger Jlink Pro (ethernet) for debugging, but am having some issues getting it working with CCS. I can connect to the debugger through CCS with no additional JLinkScript files used, but consistently get &quot;Break at address 0x0&quot; and cannot meaningfully debug without power-cycling the TMS570. Even so, I am unable to read memory or variables without pausing execution (as described here: TMS570LS1227 debug with SEGGER&#39;s JLINK - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums ). I&#39;ve followed the segger documentation for integration with Code Composer Studio, to include the inclusion of the ECC initialization skip script provided (see link below): TI Code Composer Studio - SEGGER Knowledge Base TI TMS570Lx - SEGGER Knowledge Base kb.segger.com/images/7/70/TI_TMS570Lx_SkipECCInit.JLinkScript I have used the V9.80 and V7.98 JLink Drivers with little discernable difference in outcome. When I specify the provided JLinkScript file that skips ECC initialization (to achieve my goal of connecting to the running target), I get a error that indicates a target endianness mismatch (this is not a true error). For transparency, I have been seemingly unable to add JLink through the CCS package manager. I get similar issues to here: https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/923260/ccs-adding-j-link-debugger-to-ccs I seem to have been able to get around this by replacing the dll directly in code composer studio with the up to date version from SEGGER. I (and several coworkers) tried this on CCS 10.4, 12.8, and 11.0 with similar results. Do you have any advice on how to proceed?CCSTUDIOTMS570LS1227Aerospace &amp; Defensehttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1681542/am2611-am2611-sysconfig-error-when-enabling-pru-icss-with-r5f-clock-configured-at-500-mhz/6498628Wed, 30 Sep 2026 16:55:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:bb313b83-9afa-4c7f-b71f-7489a64b2620Shaunak DeshpandeHi Kalin, The details were shared offline with some colleagues at your company. Please let me know if this issue can be closed. Regards. Shaunakhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684382/mspm33-sdk-sw-unfunctionning-after-changed-the-sdk-version/6498458Wed, 30 Sep 2026 14:11:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:211308d8-48c0-4238-843d-475f7f70e733Sebastien Le DiourisHello Ella, now it works, but not because I have done your modification but because I changed the source clock, before I used SYSOCS and I changed by crystal (external clock) Thanks for your help, I close the topichttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684382/mspm33-sdk-sw-unfunctionning-after-changed-the-sdk-version/6496616Tue, 29 Sep 2026 02:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:93789079-c4ec-4190-87c3-f72c19cef8d3Ella TangHi Sebastien, Regarding the ti_msp_dl_config.c and ti_msp_dl_config.h files, we can close the &quot;Include in build&quot; and save files to our project root folder, then we can modify the files directly. Like this: Thanks and Best Regards, Ella Tanghttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684382/mspm33-sdk-sw-unfunctionning-after-changed-the-sdk-version/6495790Mon, 28 Sep 2026 12:49:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ceaf3c94-e6ab-4a57-b921-745a0790c6b7Sebastien Le DiourisHello Ella, yes I have MCAN_init, done before SYSCTL clock. But how do you do to not generate automatically the file &quot;ti_msp_dl_config.c&quot; ? thankshttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684382/mspm33-sdk-sw-unfunctionning-after-changed-the-sdk-version/6495681Mon, 28 Sep 2026 10:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6152cbfd-2ef2-48df-8aa4-371727ae6110Ella TangHi Sebastien, We currently suspect a potential conflict in the initialization sequence. Could you please check inside the SYSCFG_DL_init() function? If SYSCFG_DL_MCAN0_init() is called before SYSCFG_DL_SYSCTL_CLK_init() , please swap their order to ensure that SYSCFG_DL_MCAN0_init() is called after the clock initialization. For example: Under this configuration, does the debug session still fail to work properly? If it remains stuck, what are the values of those registers at this point? Thanks and Best Regards, Ella Tanghttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684382/mspm33-sdk-sw-unfunctionning-after-changed-the-sdk-version/6495665Mon, 28 Sep 2026 09:44:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ec578f23-a649-4e4b-a1f5-368c53196ff8Sebastien Le DiourisHello Ella, please find below the values Best regards Sebastienhttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684382/mspm33-sdk-sw-unfunctionning-after-changed-the-sdk-version/6495607Mon, 28 Sep 2026 08:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c61a9a82-b9d2-4a5c-a529-3b08a7d90bbeElla TangHi Sebastien, Since this approach did not resolve the issue, let&#39;s revert the code back to its original state first to pinpoint the exact root cause. Then, please let the code run until it gets stuck, and export the hexadecimal values of the following four registers via the Registers window in CCS: CCR, PSR, ECR . For example: Thanks and Best Regards, Ella Tanghttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684382/mspm33-sdk-sw-unfunctionning-after-changed-the-sdk-version/6495543Mon, 28 Sep 2026 07:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6540c43c-67d6-43df-b60f-87cfe0559e78Sebastien Le DiourisHello Ella, thanks for your response, but unfortunetly, it is not better Do you confirm you requested me to do this ? Thankshttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1684382/mspm33-sdk-sw-unfunctionning-after-changed-the-sdk-version/6495328Mon, 28 Sep 2026 02:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:712559f0-b99b-42e9-84d7-3331596c64e6Ella TangHi Sebastien, In SDK 1.4.0.00, SysConfig attempts to configure MCAN before the Message RAM initialization is fully complete. Consequently, the hardware state machine locks up, and getOpMode() gets stuck indefinitely in SW_INIT mode. So we can manually reset the MCAN0 module and add a startup delay in main.c before SYSCFG_DL_init() runs. Something like this: DL_MCAN_reset(MCAN0_INST); delay_cycles(16); DL_MCAN_disablePower(MCAN0_INST); delay_cycles(32); DL_MCAN_enablePower(MCAN0_INST); delay_cycles(4000); // Wait for Message RAM initialization, about 50us. If CPU frequency is 80MHz, the cycles are 4000. SYSCFG_DL_init(); Hope the method can resolve your problem. Thanks! Best Regards, Ella Tanghttps://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1681922/tms320f28377d-ccs-build-report/6495264Sun, 27 Sep 2026 22:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2a82adc1-cd6e-404b-84d4-6f6def9e1468Takayuki MoriHi, Ira Thank you for your reply. However, I cannot find the folder you mentioned. Could this be because I am using CCS version 20.2.0.12__1.8.0 rather than Eclipse? I would appreciate your further guidance. Regards, T. Mori