• State TI Thinks Resolved
  • Replies 23 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 543 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TMS320F28377D: One or More Sections of Your Program Fall into a Memory Region that is not Writable -- Old CCS/SDK/Debugger

Michael V
Intellectual 646 points

Part Number: TMS320F28377D
Other Parts Discussed in Thread: CONTROLSUITE, POWERSUITE, SYSCONFIG

Hello,
I am currently assisting a customer with debugging a linker-related issue on the TMS320F28377D.
The customer environment is as follows:
 - CCS Version: 6.1.1.00022
 - Debug Probe: XDS100v2
 
 The issue observed during load is:
--------------------------------------------------
C28xx_CPU1: GEL Output: Memory Map Initialization Complete
C28xx_CPU1: Loader: One or more sections of your program fall into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map. 
--------------------------------------------------
At this time, I am still confirming their SDK version (possibly controlSUITE) and reviewing the linker command file. When compared to the datasheet, the defined flash regions seem to generally align with the expected device memory map.
 
Are there any known causes or common pitfalls (especially with older CCS versions such as 6.1.1) that could lead to this behavior? 
 
If you require the cmd/map files, I will need to first get permission from my customer. If granted permission, I could share via private message, so please let me know.
 
Any guidance would be appreciated.
Best regards,
Michael
  • 0
    Intellectual 646 points

    Hello,

    I have identified the SDK as one of controlSUITE v3.3.9-v3.4.3. (powerSUITE V1.05.00.00)

    My customer is currently performing software changes to a preexisting system, and as a result updating to the newest SDK/CCS may not be feasible at this time.

    Thank you,

    Michael

  • 0 in reply to Michael V
    Intellectual 646 points

    Hello,

    I have been granted permission to share the cmd+map files via private chat. I would greatly appreciate it if you could review these files and let me know if something is wrong.

    Thank you,

    Michael

  • 0 in reply to Michael V
    Intellectual 646 points

    Hello,

    I believe that the default gel file (emulation\gel\f28377d_cpu1.gel) is being used.

    I can provide the gel file, alongside the cmd and map files, for your review.

    My apologies but this is a time-sensitive issue, so I would appreciate any assistance you can provide at your earliest convenience.

    I look forward to your guidance.

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Expert 5995 points

    Hi Michael,

    Sorry for the late reply as I was OOO. Could you please share the cmd and map files?

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    Intellectual 646 points

    Hi Ira, 

    Thank you for the response.

    I've sent you a friend request so that I can share the files with you privately.

    If you have another preferred method for sharing files securely, please let me know.

    Best regards,

    Michael 

  • 0 in reply to Michael V
    TI__Expert 5995 points

    Hi Michael,

    I've sent you an email. Please check.

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    Intellectual 646 points

    Hi Ira,

    Thank you for the response.

    I have received your email and replied with both files.

    Please let me know if you need any additional information.

    Thank you,

    Michael

  • 0 in reply to Michael V
    TI__Expert 5995 points

    Hi Michael,


    Sorry for the late reply. The most likely trigger for the warning is this: sections are being placed into OTP (One-Time Programmable) memory regions that the debugger/loader considers non-writable at load time.
    From the map file:
    DCSM_OTP_Z1_LINKPOINT 00078000 0000000c 0000000c 00000000 RWIX
    DCSM_OTP_Z1_PSWDLOCK 00078010 00000004 00000004 00000000 RWIX
    DCSM_OTP_Z1_CRCLOCK 00078014 00000004 00000004 00000000 RWIX
    DCSM_OTP_Z1_BOOTCTRL 0007801c 00000004 00000004 00000000 RWIX
    DCSM_ZSEL_Z1_P0 00078020 00000010 00000010 00000000 RWIX

    All Z1 OTP sections show used = length (fully occupied) and are being actively loaded. These regions map to physical OTP flash at 0x78000

    The GEL-based Memory Map Initialization sets these regions as read-only after initialization, and the XDS100v2 loader will flag them as non-writable.
    The Z2 OTP sections, by contrast, show used = 0 they are defined but empty, which is correct behavior for an unpopulated zone.
    Specific Issues Found
    1. DCSM OTP Sections Are Loaded (Not DSECTed)
    The dcsm_otp_z1_* sections in the .cmd file are mapped directly with > (load placement). If these already contain programmed values in OTP, the loader cannot overwrite them as OTP can only be written once. This triggers the warning.
    Fix: If these sections are only needed for reading (zone configuration already programmed), they should use TYPE = DSECT or TYPE = NOLOAD

    to prevent the loader from attempting to write:
    dcsm_otp_z1_linkpointer : > DCSM_OTP_Z1_LINKPOINTER, PAGE = 0, TYPE = DSECT

    Note that DcsmZ1OtpFile and DcsmZ2OtpFile in the map file are already correctly marked as NOLOAD SECTION the same treatment should be applied to the individual DCSM OTP sections if they are already programmed.

    So here are the 2 things to try

    1. Add TYPE = DSECT or TYPE = NOLOAD to all dcsm_otp_z1_* section mappings if the OTP is already programmed.

    2. Verify whether Z1 OTP regions at 0x78000–0x7802F have already been programmed; if so, the loader cannot touch them

  • 0 in reply to Ira Thete
    Intellectual 646 points

    Hi Ira,

    Thank you for the response.

    My customer has now tested both suggestions:

    1. Added TYPE = DSECT to all dcsm_otp_z1_* section mappings.
    2. Changed the same sections to TYPE = NOLOAD.

    However, in both cases the loader warning remains unchanged.

    In addition, I checked the Z1 OTP region (0x78000–0x7802F) using the CCS Memory Browser and confirmed that some locations contain values other than 0xFF, indicating that at least part of the OTP region has already been programmed.

    Since the warning still persists even after changing the section types, I would greatly appreciate it if you could review the updated linker command file and map file to determine whether another section or memory region may be triggering the warning.

    I will send the latest .cmd and .map files through our email thread shortly. Please let me know once you have had a chance to review them.

    Thank you for your continued support.

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Expert 5995 points

    Hi Michael,

    I've received the files, I will review them and provide a reply.

  • 0 in reply to Ira Thete
    TI__Expert 5995 points

    Hi Michael,

    Apologies for the late reply, can you add both DSECT and NOLOAD explicitly as so?

    /* CPU1‑2 common DCSM sections */
    dcsm_otp_z1_linkpointer : > DCSM_OTP_Z1_LINKPOINTER, PAGE = 0, TYPE = DSECT, NOLOAD
    dcsm_otp_z1_pswdlock : > DCSM_OTP_Z1_PSWDLOCK, PAGE = 0, TYPE = DSECT, NOLOAD
    dcsm_otp_z1_crclock : > DCSM_OTP_Z1_CRCLOCK, PAGE = 0, TYPE = DSECT, NOLOAD
    dcsm_otp_z1_bootctrl : > DCSM_OTP_Z1_BOOTCTRL, PAGE = 0, TYPE = DSECT, NOLOAD
    dcsm_zsel_z1 : > DCSM_ZSEL_Z1_P0, PAGE = 0, TYPE = DSECT, NOLOAD

    dcsm_otp_z2_linkpointer : > DCSM_OTP_Z2_LINKPOINTER, PAGE = 0, TYPE = DSECT, NOLOAD
    dcsm_otp_z2_pswdlock : > DCSM_OTP_Z2_PSWDLOCK, PAGE = 0, TYPE = DSECT, NOLOAD
    dcsm_otp_z2_crclock : > DCSM_OTP_Z2_CRCLOCK, PAGE = 0, TYPE = DSECT, NOLOAD
    dcsm_otp_z2_bootctrl : > DCSM_OTP_Z2_BOOTCTRL, PAGE = 0, TYPE = DSECT, NOLOAD
    dcsm_zsel_z2 : > DCSM_ZSEL_Z2_P0, PAGE = 0, TYPE = DSECT, NOLOAD

    because I see in your .map file that there are still some bytes getting loaded to these sections, they should not be written to 

    for example, the used section in the .map for these sections should show 0

    Can you please check? I think the type-definition did not take effect. Make sure you clean and build it after making this change.

    The linker should not try to write to these sections of memory as they are not to be programmed as so, this is what is creating the error.

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    Intellectual 646 points

    Hi Ira,

    Thank you for your response.

    Upon trying out

         dcsm_otp_z1_linkpointer : > DCSM_OTP_Z1_LINKPOINTER, PAGE = 0, TYPE = DSECT, NOLOAD

    The build fails with the following error:

         #10227-D bad section property: “NOLOAD”

    Do you know what might be going wrong, and how we can solve this issue?

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Expert 5995 points

    Hi Michael, can we have a debug call for this issue? I think it will be more effective. Could you send me an email with what time works for you?

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    Intellectual 646 points

    Hi Ira,

    Thank you for your response.

    At the moment, my customer is conducting the debugging on their side, and unfortunately I am not able to be present to assist with the debugging in person.

    Because of this, I am concerned that arranging a debug call may not be feasible.

    Do you have any alternative suggestions on how we could best proceed under these circumstances?

    Thank you for your continued support.

    Best regards,
    Michael

  • 0 in reply to Michael V
    TI__Expert 5995 points

    Hi Michael,

    Ah okay, let me check with the team and see what else we can do.

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    TI__Expert 3075 points

    Hi Michael, 

    Expert is OOO this week please expect delay.

  • 0 in reply to Kunal Wasnik
    TI__Expert 5995 points

    Hi Michael,

    Can you use NOINIT instead of NOLOAD?

    /* Define the section in the .cmd file */

    dcsm_otp_z1_linkpointer : > DCSM_OTP_Z1_LINKPOINTER, PAGE = 0, TYPE = DSECT, NOINIT

    /* In your C code, declare the pointer like this */

    extern uint32_t dcsm_otp_z1_linkpointer;

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    Intellectual 646 points

    Hi Ira,

    Sorry for the delay.

    I had my customer test out your recommendation of:
    dcsm_otp_z1_linkpointer : > DCSM_OTP_Z1_LINKPOINTER, PAGE = 0, TYPE = DSECT, NOINIT

    However, they once again got the same error:
    #10227-D bad section property: “NOINIT”
     
    Please let me know if you have any suggestions, or need additional information.
     
    Best regards,
    Michael
  • 0 in reply to Michael V
    TI__Expert 5995 points

    Hi Michael,

    This is quite weird. Can any other info be shared? For example the sysconfig file? If any changes were made to the DCSM fields?

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    Intellectual 646 points

    Hi Ira,

    Thanks for the response.

    I believe they are using a version of CCS (6.1.1)  that predates sysconfig.

    Is there any other project information that would be helpful in this situation?

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Expert 5995 points

    Hi Michael,

    That is a very old version of CCS. We usually encourage moving to newer CCS for better support. However, if you must continue using this one, is it possible to share the project with me and I can try to reproduce the issue with CCS 6.1.1. You can remove sensitive source code as I just want to reproduce the linker issue. Because we have tried all the linker directives (NOINIT, NOLOAD etc) and they are all unsupported by this older CCS. I think the only way forward is to try to reproduce the issue now.

    Is it feasible to share the project? Feel free to remove sensitive functions etc. , I just want to reproduce the linker issue.

    Thanks,

    Ira

  • 0 in reply to Ira Thete
    Intellectual 646 points

    Hi Ira,

    Thank you for the response.

    I requested a version of their project with sensitive code removed, but my clients internal checks are taking longer than expected.

    I'll send an update when I get more information.

    Best regards,

    Michael

  • 0 in reply to Michael V
    TI__Expert 5995 points

    Sure, Thanks.