https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1653843/am625-q1-am625-ddr-sysconfig-configuration-issues/6388327Thu, 18 Jun 2026 21:22:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7f6abd68-cf88-4d81-8655-945ac61d1640JJDDensity setting is per device. Since you are using 2 x8 devices 1Gx8, it should be set to 8, not 16. Try running your tests with this change. Regards, Jameshttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1654963/mspm0l1117-bootrst-reset-don-t-reset-sram-memory/6388231Thu, 18 Jun 2026 19:50:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:186c2b4b-5593-4c9d-937c-1fdb8d2e026dJD CrutchfieldHello Kostadin, I&#39;ve dug more into this for you. As I mentioned, generally SRAM is not initialized in that when it is &quot;reset&quot; or power-cycled has no guaranteed starting state. This is also mentioned in this note of the TRM. When you compiler your code, any initialized variable in SRAM will be configured by some runtime startup code that runs before you reach main(). In your case, the MSPM0L1306 is operating how I would expect and it&#39;s MSPM0G3507 that I&#39;m surprised that the SRAM has been &quot;cleared.&quot; which I interrupt as being written all 0x00. I spoke with team, and learned that this is an expected difference between MSPM0&#39;s with no SRAM parity/ECC (MSPM0L1306) and devices that do have parity/ECC (G3507). On the devices with Parity or ECC, we actually did add hardware initialization to SRAM so that you wouldn&#39;t immediately get parity/ECC errors if you accessed it as mentioned in that above TRM note. On devices without ECC, this hardware initialization is not added and these devices continue to have random SRAM values. Hopefully this clarifies this behavior you are observing. Let me know if you have any additional follow-up questions. Thanks, JDhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1649753/am2434-voltage-isolation-of-m4f-in-isolated-mode/6388091Thu, 18 Jun 2026 17:28:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9271d7e6-1e32-4023-b301-a4e9f8ef164bKallikuppa SreenivasaHello Manuel, Thank you for checking. I am following up internally. Can you please help me understand the source of the diagram you shared above. REgards, Sreenivasahttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656374/tms570lc4357-tms570lc43457-multi-buffer-spi-rx-not-triggering-rxdma/6388081Thu, 18 Jun 2026 17:19:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fc38b7b6-f97a-46d5-bfa8-038147aa2320Fabian HofThanks for your reply. I believe I have narrowed it down (DMA channel/map misconfiguration). Unfortunately, most of these examples do not use multi-buffer mode and only use the SPI in compatibility mode + DMA. So I still have one critical question: what do we have to set BUFMOD to? From the documentation, I understand we need to set either 6 or 7, as we need to wait for RXEMPTY. I currently set mibspiRAM1-&gt;tx[0 - N-1].control.BUFMODE = 5 and mibspiRAM1-&gt;tx[N].control.BUFMODE = 6 . Unfortunately, I can&#39;t look at the examples for the LS3137 — it says I do not have permission to download the files. ( /cfs-file/__key/communityserver-discussions-components-files/908/2526.testDMA.zip ) Is there a way I can access these files?https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656398/am263p4-q1-questions-about-msram-allocation-in-am263px-sbl-ospi-linker-cmd/6388001Thu, 18 Jun 2026 16:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:662b62d9-b72e-409b-8979-4e8bd21d6c21Aswin SankarHi Imaoka-San, [quote userid=&quot;633951&quot; url=&quot;~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656398/am263p4-q1-questions-about-msram-allocation-in-am263px-sbl-ospi-linker-cmd&quot;]Q1: MSRAM_VECS start address 0x70002000 In the linker script, MSRAM_VECS starts at 0x70002000. Can the address range 0x70000000–0x70001FFF (the first 8KB) be used by the SBL? If this region is reserved, what is it used for?[/quote] The region MSRAM_VECS contains the vectors of the SBL. This is required for the proper loading of SBL by ROM. On bootup ROM wakes up and it loads the .vectors section of SBL into 0x7000_2000 address in RAM.This address is mentioned as load address in the linker script. See that the run address is kept as 0x0 for the .vectors section. That is because when eclipsing happens the vectors get moved to 0x0 address and execution happens from there. Therefor this address should not be changes and should be intact. [quote userid=&quot;633951&quot; url=&quot;~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656398/am263p4-q1-questions-about-msram-allocation-in-am263px-sbl-ospi-linker-cmd&quot;]Can the address range 0x70000000–0x70001FFF (the first 8KB) be used by the SBL? If this region is reserved, what is it used for?[/quote] This is the area used by ROM for execution. If the SBL uses this area then, when ROM loads SBL it will overwrite itself. But one thing to notice is that, you can configure the .bss section of SBL to use this area. This is because .bss is not loaded since it is uninitialized and hence there is no risk of overwriting. [quote userid=&quot;633951&quot; url=&quot;~/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656398/am263p4-q1-questions-about-msram-allocation-in-am263px-sbl-ospi-linker-cmd&quot;]Q2: Reducing MSRAM_HSMRT size From my side, it looks like MSRAM_HSMRT actual usage is only about ~26KB. Is it safe to reduce the allocated size of MSRAM_HSMRT? If there is a minimum required size or any constraint, could you please advise?[/quote] You may reduce the size of MSRAM_HSMRT depending on your application. Thanks &amp; Regards, Aswinhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656387/lp-em-cc2340r5-lp-em-cc2340r5/6387969Thu, 18 Jun 2026 16:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:31e6d625-cb77-4758-92f5-d1dcf1108f9aMopel KiteleHi, Here are some links to some resources that can provide more insight into your design process, and answer potential questions you may have about Channel Sounding: https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/9.12.00.19/exports/docs/ble5stack/ble_user_guide/html/channel-sounding/channel-sounding.html https://www.ti.com/lit/an/swra791/swra791.pdf?ts=1781798301525&amp;ref_url=https%253A%252F%252Fwww.google.com%252F https://www.ti.com/video/6387256178112 https://www.ti.com/video/6366746223112https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656468/am2612-xip-file-programming-question/6387967Thu, 18 Jun 2026 16:10:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:38cff80f-44c6-4f28-9451-af82d52b8a2eAswin SankarHi Kita, Can you please explain what does packaging information and mcelf_xip write interface mean here? You always have the option to flash the xip image using uniflash, in this method you can flash files or huge sizes Thanks &amp; Regards, Aswinhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656387/lp-em-cc2340r5-lp-em-cc2340r5/6387928Thu, 18 Jun 2026 15:52:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a4adaa2d-509f-498f-9681-0c3a9b00c7eaMopel KiteleHello Atilano, The CC2340R5 will certainly suit that application, however, you will have to make the PCB that the chip will go on. We can assist with debugging software/hardware related issues in this process of creation, but it will ultimately be designed by you. Texas Instruments does not sell key fobs. You take ownership of the final product, TI will help you with the development process.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656387/lp-em-cc2340r5-lp-em-cc2340r5/6387901Thu, 18 Jun 2026 15:40:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:76397e4a-056a-4113-859e-99f99c20589dAtilano ValadezHi, Could you please recommend a Texas Instruments key fob that is compatible with the CC2340R5? Please see attached image as a reference onlyhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656634/mspm0-sdk-unable-to-connect-target-dap-connection-error---mspm0c1104-20-pin-controller/6387886Thu, 18 Jun 2026 15:33:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:fef2b04b-b1b2-406d-8499-3a068b08faf0Brian LeeHi Nandini, In your first attached image it looks like you were able to connect to the DAP core. Can you do this again, run the Device Diagnostic Read script, and share the results? Best Regards, Brianhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656611/mspm0g3507-bim-together-with-secondary-bsl/6387854Thu, 18 Jun 2026 15:15:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:6da55573-6177-4564-b0c0-1039f91069d2Brian LeeHi Zq, When invoking the secondary bootloader from your application, are you accounting for BSL_ERR_01 from the MSPM0G3507 Errata ? Best Regards, Brianhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656387/lp-em-cc2340r5-lp-em-cc2340r5/6387836Thu, 18 Jun 2026 15:04:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:f0c262f0-480e-4d04-a5d6-204497b1f03cMopel KiteleGreetings Atilano, Yes, you will need extra hardware to connect the LP-EM-CC2340R5 to the USB port on your PC. The LP-EM-CC2340R5 is an evaluation module, meaning it does not have an onboard debugger nor a USB connector. Therefore, to connect it to your PC, you will need an LP-XDS110, which is an external debug probe that connects to the LP-EM-CC2340R5 via the 10-pin JTAG/SWD header. Once this connection has been made, connect the LP-XDS110 to your PC via a USB-A to Micro-B cable. Refer to this link to procure the LP-XDS110: https://www.ti.com/tool/LP-XDS110#included , the necessary USB-A to Micro-B cable is included within this package.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1645809/am263p4-q1-regarding-writing-to-a-flash-region-with-cache-enabled/6387787Thu, 18 Jun 2026 14:39:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2f4bc72f-aec3-4c01-bb23-47d6e202275bFleenorHi Imaoka-san, Looking at the screenshot, the write of 128KB of 0x00 data to 0x88620000 resulted in: Addresses 0x88620000 – 0x886200F7 : 0xFF84FF84 pattern (incorrect — neither 0x00 nor erased 0xFF ) Addresses 0x886200F8 onward: 0xFFFFFFFF (erased state — write did not take effect) This is not a Region 3 access problem . This is a flash programming protocol violation . The memcpy() approach is writing raw bytes to the OSPI DAC window without respecting the flash device&#39;s required write sequence (Write Enable → Page Program command → wait for completion). Root Cause: Why Direct memcpy() to DAC Does Not Work for Flash Write DAC (Direct Access Controller) mode on OSPI allows memory-mapped reads from flash transparently. However, memory-mapped writes through DAC do not automatically issue the correct flash programming commands to the NOR flash device. A NOR flash write requires: WREN (Write Enable latch command 0x06 ) Page Program command ( 0x02 or 0x12 ) with address and data WIP polling (Wait for Write-In-Progress bit to clear in Status Register) A raw memcpy() to the DAC window bypasses this sequence entirely, which is why only partial and corrupted data appears. Direct Answer to Your Question Is it acceptable to operate with the bounds check removed? Yes, this is the correct and recommended path for your use case. Here is the reasoning: The bounds check in Flash_norOspiRead() / Flash_write() : if ((offset + len) &gt; (attrs-&gt;flashSize)) { status = SystemP_FAILURE; } This check was designed to prevent accidental out-of-bounds access on a single contiguous flash device . It was not designed with the FSS multi-region address map in mind . When you pass a Region 3 offset (e.g., 0x28280000 ) the check incorrectly rejects a valid access. The underlying OSPI driver, below the bounds check, does not care about which FSS region the address belongs to — it constructs flash commands using the physical offset into the flash device. The physical offset is what matters for the hardware. Recommended Implementation Step 1: Create a Wrapper That Bypasses the Bounds Check Rather than modifying the SDK source file directly (which complicates future SDK updates), create a local wrapper: #include &quot;flash_nor_ospi.h&quot; /* or appropriate internal header */ #define FSS_REGION0_BASE (0x60000000U) #define FSS_REGION3_BASE (0x88000000U) #define FSS_REGION3_OFFSET (FSS_REGION3_BASE - FSS_REGION0_BASE) /* 0x28000000 */ /** * Convert a Region 3 offset back to a Region 0 physical offset * for use with Flash APIs that perform bounds checking. * * physical_offset = region3_offset - 0x28000000 */ static inline uint32_t region3OffsetToPhysical(uint32_t region3Offset) { return (region3Offset - FSS_REGION3_OFFSET); } /** * Convert a Region 0 (cached) address to a Region 3 (bypass) absolute address * for use with direct memory pointer reads. */ static inline uint32_t cachedAddrToBypassAddr(uint32_t cachedAddr) { return (cachedAddr - FSS_REGION0_BASE + FSS_REGION3_BASE); } Step 2: Use Flash_write() with Region 0 Physical Offset int32_t flashBypassWrite(Flash_Handle handle, uint32_t physicalOffset, /* Region 0 offset, e.g. 0x00280000 */ uint8_t *buf, uint32_t len) { /* * Flash_write() with Region 0 offset: * - Passes bounds check (offset &lt; flashSize) * - Internally constructs correct Page Program sequence * - ECCM is bypassed because the OSPI controller accesses * physical flash directly, not through the FSS ECC pipeline * when the Flash driver constructs explicit commands */ return Flash_write(handle, physicalOffset, buf, len); } Step 3: Use Region 3 Pointer for Verification Read int32_t flashBypassVerify(uint32_t physicalOffset, uint8_t *expectedBuf, uint32_t len) { /* * Calculate Region 3 absolute address for bypass read. * Reading through Region 3 bypasses ECCM and cache, * giving direct flash contents. */ uint8_t *bypassPtr = (uint8_t *)(FSS_REGION3_BASE + physicalOffset); if (memcmp(bypassPtr, expectedBuf, len) != 0) { return SystemP_FAILURE; } return SystemP_SUCCESS; } Step 4: Complete Flash Update Sequence int32_t flashUpdateSector(Flash_Handle handle, uint32_t cachedBaseAddr, /* e.g. 0x60280000 */ uint8_t *newData, uint32_t dataLen) { int32_t status; uint32_t sectorNum, pageNum; /* Calculate Region 0 physical offset from cached address */ uint32_t physOffset = cachedBaseAddr - FSS_REGION0_BASE; /* e.g. 0x60280000 - 0x60000000 = 0x00280000 */ /* Step 1: Get sector number using physical offset */ status = Flash_offsetToSectorPage(handle, physOffset, &amp;sectorNum, &amp;pageNum); if (status != SystemP_SUCCESS) { return status; } /* Step 2: Erase sector (uses sector number, no address bounds issue) */ status = Flash_eraseSector(handle, sectorNum); if (status != SystemP_SUCCESS) { return status; } /* Step 3: Write using Region 0 physical offset */ status = Flash_write(handle, physOffset, newData, dataLen); if (status != SystemP_SUCCESS) { return status; } /* Step 4: Verify by reading through Region 3 bypass pointer */ status = flashBypassVerify(physOffset, newData, dataLen); return status; } Why This Works Correctly Operation Method Why It Works Flash_eraseSector() Sector number (physical index) No address/offset involved, no bounds check issue Flash_write() Region 0 offset ( 0x00280000 ) Passes bounds check; OSPI driver issues correct Page Program sequence to physical flash Verification read Region 3 pointer ( 0x88280000 ) Direct memory read bypasses cache and ECCM; reflects true flash contents Regarding the ECCM Concern with Flash_write() + Region 0 Offset You may be concerned that using Flash_write() with a Region 0 offset will encounter ECCM issues. The important clarification is: Flash_write() does not write through the FSS ECC pipeline. It constructs an explicit OSPI Page Program command that is sent directly to the flash device over the OSPI bus. The FSS ECCM only intercepts memory-mapped (DAC) writes , not explicit command-mode flash programming transactions. Therefore: Flash_write() → issues Page Program command via OSPI command mode → no ECCM interaction memcpy() to DAC window → memory-mapped write → would go through ECCM (and also lacks the proper write enable/program sequence) This means Flash_write() with the Region 0 physical offset is safe and correct for your use case. Summary of Recommended Approach Erase: Flash_eraseSector(handle, sectorNum) ← unchanged, works correctly Write: Flash_write(handle, physOffset, buf, len) ← use Region 0 offset (0x00280000) Verify: memcmp((uint8_t*)(0x88000000 + physOffset), ← use Region 3 pointer buf, len) No SDK source modification is required. No memcpy() to DAC window. No bounds check removal needed. Best Regards, Zackary Fleenorhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656446/pmp41114-need-digital-control-sw-and-hw-support/6387764Thu, 18 Jun 2026 14:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:a8108a0a-d4e9-4228-990b-d8e9dd0ad751Desheng, GuoHi Murli, This design is combined with PMP23338 and PMP41138. The PMP23338 is released, and orderable; PMP41138 we haven&#39;t release it yet, you can reach out TI FAE to request from us.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656162/am263p4-q1-am263p4-soldering-and-reflow-profile/6387744Thu, 18 Jun 2026 14:09:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0f7e6d87-fb11-4035-9cae-487071103c1eFleenorHi Jayakeerthana, The AM263P4-Q1 uses an NFBGA (ZCZ) 324-pin package with a moisture sensitivity level of MSL Level-3-260C-168 HR [ 1 ]. This means: Peak reflow temperature: 260&#176;C maximum [ 1 ] Floor life: 168 hours at ≤30&#176;C / 60% RH after removal from dry pack Reflow profile: Must comply with IPC/JEDEC J-STD-020 for moisture sensitivity Level 3 components Key Assembly Resources For PCB guidance specific to the AM263x family (refer to the AM263x Hardware Design Guide , Section on PCB Assembly [ 2 ]. General Reflow Guidelines (per J-STD-020 for MSL-3, 260&#176;C) Parameter Specification Peak temperature 260&#176;C max Time above 217&#176;C (liquidus) 60–150 seconds Ramp-up rate 3&#176;C/s max Preheat/soak 150–200&#176;C for 60–120 seconds Peak time (within 5&#176;C of peak) 20–40 seconds Ramp-down rate 6&#176;C/s max Note: The exact time-temperature curve values above are standard JEDEC J-STD-020 guidelines for this MSL/package classification. Always validate against your solder paste manufacturer&#39;s recommendations and your specific board thermal mass. (Excerpt from: AN-1126 BGA (Ball Grid Array) (Rev. C) ) Handling Requirement Since this is an MSL-3 device, if the dry-pack seal is broken for more than 168 hours, baking is required before reflow (typically 24 hours at 125&#176;C per J-STD-033). AM263P4 Datasheet - Packaging Information AM263x Hardware Design Guide - PCB Assembly MSL Ratings and Reflow Profiles (Rev. A) https://www.ti.com/lit/an/snoa021c/snoa021c.pdf Best Regards, Zackary Fleenorhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656666/lp-am261-required-software-modification-by-phy-change-dp83869--dp83826a/6387743Thu, 18 Jun 2026 14:08:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7c67e821-1c22-4f63-a524-f5cd7adf050dTed HuhI will try this. thanks Regards, Tedhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656666/lp-am261-required-software-modification-by-phy-change-dp83869--dp83826a/6387738Thu, 18 Jun 2026 14:05:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2103ad72-dc1c-4f8c-95ed-78b3e36a0932Nilabh AnandHi Ted, I am assuming customer is using the beckhoff ethercat example? Please ask customer to follow this for debug: https://www.ti.com/lit/an/snla344c/snla344c.pdf Also Please follow Ethercat debug guide here - software-dl.ti.com/.../ETHERCAT_SUBDEVICE_FWHAL.htmlhttps://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656666/lp-am261-required-software-modification-by-phy-change-dp83869--dp83826aThu, 18 Jun 2026 13:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:89fa84e4-1935-4f14-b351-bcd5a57e2272Ted HuhPart Number: LP-AM261 Other Parts Discussed in Thread: DP83869 , SYSCONFIG Hello ASM Team, My customer built the custom board with same pinmap as LP-AM261. but they changed PHYs from DP83869(enhanced mode) to DP83826A(basic mode). with this change, Link down occurs and it cannot commnicate with TwinCAT PC. I changed PHY setting from DP83869 to DP83826A in sysconfig. also cleared the check box for enhanced mode but still it does not work. is there any modification required for firmware side also? Regards, TedLP-AM261SYSCONFIGRoboticsDP83869https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656634/mspm0-sdk-unable-to-connect-target-dap-connection-error---mspm0c1104-20-pin-controller/6387670Thu, 18 Jun 2026 13:13:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c1d39284-3420-4c6a-995f-f9e98a97fcf9Nandini VKIn the Threads view, I connected to the target CORTEX_M0P and clicked View All Cores . It displayed CS_DAP_0 and SEC_AP . While holding the reset button, I selected Factory Reset Manual . However, the operation failed and I received the error shown like this.https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1656634/mspm0-sdk-unable-to-connect-target-dap-connection-error---mspm0c1104-20-pin-controllerThu, 18 Jun 2026 12:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:935ace2f-123a-4883-9b48-2f7887d99ec4Nandini VKPart Number: MSPM0-SDK Other Parts Discussed in Thread: MSPM0C1104 , UNIFLASH Hi Team, I am using the MSPM0C1104 microcontroller. While flashing the application, I encountered the error shown in the attached image. I reviewed previous forum discussions related to the same issue and followed the suggested recovery procedure of holding the reset pin and performing a factory reset. However, I was unable to complete the factory reset successfully. I also attempted to perform a factory reset using UniFlash, the GUI tool, and CCS IDE, but the issue persists and I am still unable to flash the program onto the device. Could you please help me resolve this issue? Thank you.UniFlashMSPM0C1104MSPM0-SDK