TMS320F28388D: F28388D SDFM register values not updating in CCS when connected with ICE

Part Number: TMS320F28388D

Tool/software:

My customer using the F28388D device and observed an issue with the SDFM registers when debugging in CCS.

a. When he connects CCS with ICE(JTEG), the value in Sdfm1Regs.SDDATA1.bit.DATA32HI and Sdfm1Regs.SDDATA2.bit.DATA32HI are not updated, but when he runs the code without ICE connected, the values can be updated normally.

could this be related to CCS/JTAG settings? 

  • Hello Clark,

    This is most likely a debug/visibility issue, not an SDFM fault. Can you make sure you enable “Real-Time Mode + continuous refresh”?

    Also, note that Many peripherals (like ePWM) have FREE bits for “run free on suspend,” but SDFM does not. If you hit a breakpoint or press suspend, the SDFM data path will stop updating and the last values will sit in SDDATAx until you resume. So, observe SDFM while the program is running, not at a breakpoint.

    You can also try Watch or Memory Browser. Use Sdfm1Regs.SDDATA1.all (or .u32), or read the 32-bit address in the Memory Browser with 32-bit access. Looking only at .bit.DATA32HI can be misleading during live updates.

    Please let me know if this resolves the issue. If you still see no updates while running with real-time mode + continuous refresh, share: CCS version, GEL/CCXML target config, and a minimal snippet showing how you configure SDFM + where you read SDDATAx. 

    Best Regards,

    Masoud

  • Hi Masoud,

    When running code under ICE without setting a breakpoint (Program keeps running), even though current flows in, the values read from Sdfm1Regs registers do not change.

    She fell this may not be related to enabling “Real-Time Mode + continuous refresh”.

    Could you please let me know if there are any other possible reasons? Thank you.

    Best Regards,

    Clark Wu

  • Hi Clark,

    Thanks for the added detail. If the program is running (no breakpoints) and Sdfm1Regs.SDDATAx still appears static in CCS, that usually points to a visibility/clocking or read-method issue rather than an SDFM hardware fault. Please try reading the full 32-bit SDDATA register (Sdfm1Regs.SDDATA1.all or via Memory Browser with 32-bit accesses) instead of only .bit.DATA32HI. Reading a single half-word during live updates can be misleading and look “stuck.”

    Also, if you derive SDx_C from an ePWM , make sure TBCLKSYNC is enabled and each ePWM used is set to FREE_SOFT = 2 (run-free on suspend). Otherwise, attaching the debugger or briefly halting can stop the clocking chain and the SDFM output will freeze at the last value. 

    If it still doesn’t move after the above, please share minimal CCS version and target config (CCXML), and with that, we can reproduce and dig deeper.

    Best regards,
    Masoud