• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 331 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28377D: The problem that an initialized global variable is not initialized after booting

Jaejun Yun
Prodigy 115 points

Part Number: TMS320F28377D

Hi,

I am having a problem with my development using the 28377D MCU.

I have a global variable that is initialized with a value at declaration, but after booting, the value is changed to '0' or an invalid value when I check it in the Watch Window.

I have found forum posts that suggest this is a problem that occurs in GS RAM, but I did not declare the variable in the GS RAM region.

I would appreciate any suggestions you have on how to troubleshoot this issue.

Thanks,

  • 0
    Prodigy 115 points

    The problem only occurs when the program is run on CPU2. When the program is run on CPU1 single-core, the problem does not occur.

  • 0 in reply to Jaejun Yun
    TI__Mastermind 30185 points

    Hello Jaejun,

    Is this variable something that is on both CPUs? Are you making sure to select the proper core during the debug session so it's not remaining on CPU1 when you execute the program? You can do this by selecting the appropriate core in the Debug Session window. Please also show the Memory Browser for the variable's location with the proper core selected.

    Best regards,

    Omer Amir

  • 0
    Prodigy 115 points

    I checked and found that the variable is in the GS RAM region.

    I was unaware that the compiler could place a variable in the GS RAM region during compilation because I did not explicitly declare the location of the variable when declaring it.

    However, even if this is the case, the problem is still strange.

    As shown in the figure below, I tried to prevent the compiler from unnecessary access by considering the area that CPU2 should exclusively use in CMD.

    <Figure. CPU1 CMD>

    When I checked the location of the variable that is causing the problem, it was located in GS8 RAM.

    <Figure. CPU2 CMD>

    I am currently developing with a debugger connected, and I am writing to the Flash and loading it through the debugger to run the program.
    When I open the debugger section, CCS automatically writes to CPU1 first, and then to CPU2.
    After the writing is complete, CPU1 and CPU2 are located in the main, and they are in a suspended state due to a hardware break.
    In this state, I run CPU1 first, and then CPU2 after a while.

    As shown in the figure below, CPU1 assigns permissions to the GS RAM during booting.

    I am not sure which part of my work is wrong. Can you help me to identify the problem?

  • 0 in reply to Jaejun Yun
    TI__Mastermind 30185 points
    Jaejun Yun said:
    I was unaware that the compiler could place a variable in the GS RAM region during compilation because I did not explicitly declare the location of the variable when declaring it.

    If you do not declare it and it's in a global space, it will likely be placed in global memory depending on the linker command file configuration.

    Jaejun Yun said:
    As shown in the figure below, I tried to prevent the compiler from unnecessary access by considering the area that CPU2 should exclusively use in CMD.
    Jaejun Yun said:
    When I checked the location of the variable that is causing the problem, it was located in GS8 RAM.

    Can you please show the sections part of the linker command file?

    Jaejun Yun said:
    I am not sure which part of my work is wrong. Can you help me to identify the problem?

    I think I'm not fully understanding the problem here, is it just that you're trying to place a variable at a specific memory unit but this is not occurring?