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.

CCS/TMS320F28379D: Loading to RAM instead FLASH overwrites instruction with ESTOP0 at main entry

Part Number: TMS320F28379D
Other Parts Discussed in Thread: CONTROLSUITE

Tool/software: Code Composer Studio

Hi,

when I load my code to RAM instead to FLASH the fist instruction at the entry of main is replaced by a ESTOP0. The overwritten instruction moved the stackpointer. As this is missing in RAM execution moves the stackpointer, the stack underflows and overwrites other code. Eventually the application crashes.

When debugging the MCU also stops twice at the main entry.

Disassembly when loaded to RAM:

        main():
014405:   7625        ESTOP0       
40        volatile boolean_T runModel = 1;
014406:   56BF0141    MOVB         *-SP[1], #0x01, UNC
41        float modelBaseRate = 0.2;
014408:   2844CCCD    MOV          *-SP[4], #0xcccd
01440a:   28433E4C    MOV          *-SP[3], #0x3e4c
42        float systemClock = 200;
01440c:   E8021A40    MOVIZ        R0, #0x4348
01440e:   E2030046    MOV32        *-SP[6], R0H
43        c2000_flash_init();

Disassembly when loaded to FLASH:

        main():
0816eb:   FE06        ADDB         SP, #6
40        volatile boolean_T runModel = 1;
0816ec:   56BF0141    MOVB         *-SP[1], #0x01, UNC
41        float modelBaseRate = 0.2;
0816ee:   2844CCCD    MOV          *-SP[4], #0xcccd
0816f0:   28433E4C    MOV          *-SP[3], #0x3e4c
42        float systemClock = 200;
0816f2:   E8021A40    MOVIZ        R0, #0x4348
0816f4:   E2030046    MOV32        *-SP[6], R0H
43        c2000_flash_init();

The code is generated using Simulink and the embedded coder. CCS Version is 6.2.

As far as I can see the only difference in the build process is --define=BOOT_FROM_FLASH=0/1 .

What could be the reason for this?

Best regards,

Thomas.

  • Thomas,

    That ESTOP is a software breakpoint.  CCS is configured to run to main() after you load the program.  When you are loading to RAM CCS will use a software breakpoint for this.  When you hit run after the breakpoint has been hit CCS will put the original opcode back in place prior to running.   This should not be causing the behaviour you are seeing.  When running from Flash a software breakpoint cannot be used so CCS is using a hardware breakpoint resource.

    It is possible to disable the run to main() if you want to confirm if this is causing the problem you are seeing.

    Before launching your debug session go to the properties for your project and either clear main from the box for the symbol to run to or uncheck the box to run to it on load and restart.

    Regards,

    John

  • Hi John,

    thanks for your help!

    I tried option you suggested and the behaviour is still almost identical.

    When starting to debug it doesn't stop at main, but at c_int00() (as expected). The ESTOP0 at the main entry is still in place. An the Debugger also stops there, but now just once (before it stopped twice at the same location, both stops where shown as SW Breakpoints in the Debug tab).

    Might it happen that the SW-Breakpoint is set twice, and one is never replaced by the real code?

    I also checked the generated .asm file. There is the correct code at main entry.

    One more thing: This happens only with the Projects generated by Simulink. When I load an example, everything is fine.

    Best regards,

    Thomas.

  • Thomas,

    Yes it does seem like something else is setting that software breakpoint. I am not very familiar with Simulink. I don't know if it gives you such an option.

    If you look in the breakpoints view in CCS does it show a breakpoint there? If something other than CCS is inserting that then CCS wouldn't know to swap in the appropriate opcode later (plus it wouldn't know what it is). I will check if there is a way to show the system breakpoints that CCS sets.

    Regards,
    John
  • Hi John,

    I checked the breakpoints view, and it's empty. Neither the ESTOP0-breakpoint nor the breakpoint at main entry is visible there.

    The embedded coder of Simulink just creates the code files and the CCS project. Then there is no connection anymore. So debugging is done only in CCS. But all the options and settings are done by Simulink. So my guess is that there goes something wrong.

    I also checked CCSv7 and it's the same thing.

    Best regards,

    Thomas.

  • Hi,

    Please update on the version of the MATLAB you are seeing this issue. like for example: 2017a??

    Regards,

    Venkatesh C

  • Hi Venkatesh,

    my Versions are:

    MATLAB: 2017a

    Embedded Coder Support Package for TI C2000: 17.1.3

    CCS: 6.2.0.00050

    Best regards,

    Thomas.

  • Thomas78173 said:
    I checked the breakpoints view, and it's empty. Neither the ESTOP0-breakpoint nor the breakpoint at main entry is visible there.

    I think the breakpoints view filters out some breakpoints which can be set automatically by CCS.

    Therefore, suggest you open the Scripting Console and type:

    js:> eval("DEBUG_DumpBreakpoints()")

    and cut and paste the output that appears in the Console view to this thread.

    That should report all the breakpoints, and what set the breakpoints.

  • Hi Chester,

    I followed your instructions, and here are the results. For comparison I also tried with the blinky_demo (which works fine) and without the run to main option (see above). To be honest I don't see much difference. I hope you can see more.

    my project, with run to main

    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Logical Breakpoints: 17
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Software Physical Breakpoints: 21
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Legacy Hardware Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated 55 Hardware Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Thread Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump: Enabled: 0
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump: Disabled: 4
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$EXIT" (0xa7c9)
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Terminate Program Execution
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$EXITE"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Terminate Program Execution
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$IO$$"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Process CIO
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$IOE$$"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Process CIO
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system

    my project; without run to main

    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Logical Breakpoints: 17
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Software Physical Breakpoints: 21
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Legacy Hardware Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated 55 Hardware Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Thread Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump: Enabled: 0
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump: Disabled: 4
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$IO$$"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Process CIO
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$IOE$$"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Process CIO
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$EXIT" (0xa7c9)
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Terminate Program Execution
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$EXITE"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Terminate Program Execution
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system

    blinky_demo; with run to main

    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Logical Breakpoints: 16
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Software Physical Breakpoints: 20
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Legacy Hardware Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated 55 Hardware Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Thread Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump: Enabled: 0
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump: Disabled: 4
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$EXITE"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Terminate Program Execution
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$IOE$$"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Process CIO
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$IO$$"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Process CIO
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$EXIT" (0xb5fb)
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Terminate Program Execution
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system

    blinky_demo; without run to main

    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Logical Breakpoints: 16
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Software Physical Breakpoints: 20
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Legacy Hardware Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated 55 Hardware Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump: Total Allocated Thread Physical Breakpoints: 0
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump: Enabled: 0
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump: Disabled: 4
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$IO$$"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Process CIO
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$IOE$$"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Process CIO
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$EXIT" (0xb5fb)
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Terminate Program Execution
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system
    C28xx_CPU1: Breakpoint Manager Dump:
    C28xx_CPU1: Breakpoint Manager Dump:  Hardware Configuration
    C28xx_CPU1: Breakpoint Manager Dump:   Location: "C$$EXITE"
    C28xx_CPU1: Breakpoint Manager Dump:  Debugger Response
    C28xx_CPU1: Breakpoint Manager Dump:   Condition:
    C28xx_CPU1: Breakpoint Manager Dump:   Skip Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:    Current Count: 0
    C28xx_CPU1: Breakpoint Manager Dump:   Action: Terminate Program Execution
    C28xx_CPU1: Breakpoint Manager Dump:  Miscellaneous
    C28xx_CPU1: Breakpoint Manager Dump:   Group: Default Group
    C28xx_CPU1: Breakpoint Manager Dump:   Name:
    C28xx_CPU1: Breakpoint Manager Dump:  Breakpoint set by the system

    Best regards,

    Thomas.

  • The exit label and CIO breakpoints are set but I don't see the others. I suspect that Simulink is embedding the estop. Is the disassembly shown in your first post from the CCS disassembly view or from the listing file generated by the compiler?

    John
  • Hi John,

    the listing from the first post was copied from the CCS disassembly view while debugging. The .asm file generated by the compiler has no ESTOP0 at this place, but the normal instruction.

    Just in the moment I could reproduce the behaviour with the blinky example from the controlSUITE. The only thing changed by me is that I moved the .text section to GS8RAM, as it is done by the generated code / project.

    with original linker command file:

            main():
    00b5cb:   76408000    LCR          InitSysCtrl
     40         EINT;
    00b5cd:   2910        CLRC         INTM
     46         InitGpio();
    00b5ce:   FF69        SPM          #0
    00b5cf:   76400140    LCR          InitGpio
     47         GPIO_SetupPinMux(BLINKY_LED_GPIO, GPIO_MUX_CPU1, 0);
    00b5d1:   9A1F        MOVB         AL, #0x1f
    00b5d2:   D400        MOVB         XAR4, #0x0
    00b5d3:   9B00        MOVB         AH, #0x0
    00b5d4:   76400180    LCR          GPIO_SetupPinMux


    .text in GS8RAM:

            main():
    014ba0:   7625        ESTOP0      
    014ba1:   4585        TBIT         *XAR5++, #0x5
     40         EINT;
    014ba2:   2910        CLRC         INTM
     46         InitGpio();
    014ba3:   FF69        SPM          #0
    014ba4:   764148C0    LCR          InitGpio
     47         GPIO_SetupPinMux(BLINKY_LED_GPIO, GPIO_MUX_CPU1, 0);
    014ba6:   9A1F        MOVB         AL, #0x1f
    014ba7:   D400        MOVB         XAR4, #0x0
    014ba8:   9B00        MOVB         AH, #0x0
    014ba9:   76414900    LCR          GPIO_SetupPinMux

    My modified linker command file (changes bold):

    MEMORY
    {
    PAGE 0 :
       /* BEGIN is used for the "boot to SARAM" bootloader mode   */

       BEGIN            : origin = 0x000000, length = 0x000002
       RAMM0            : origin = 0x000122, length = 0x0002DE
       RAMD0            : origin = 0x00B000, length = 0x000800
       RAMLS0           : origin = 0x008000, length = 0x000800
       RAMLS1           : origin = 0x008800, length = 0x000800
       RAMLS2        : origin = 0x009000, length = 0x000800
       RAMLS3        : origin = 0x009800, length = 0x000800
       RAMLS4        : origin = 0x00A000, length = 0x000800
       RESET            : origin = 0x3FFFC0, length = 0x000002

    // TW:
       RAMGS8      : origin = 0x014000, length = 0x001000
       RAMGS9      : origin = 0x015000, length = 0x001000


    PAGE 1 :

       BOOT_RSVD       : origin = 0x000002, length = 0x000120     /* Part of M0, BOOT rom will use this for stack */
       RAMM1           : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */
       RAMD1           : origin = 0x00B800, length = 0x000800


       RAMLS5      : origin = 0x00A800, length = 0x000800

       RAMGS0      : origin = 0x00C000, length = 0x001000
       RAMGS1      : origin = 0x00D000, length = 0x001000
       RAMGS2      : origin = 0x00E000, length = 0x001000
       RAMGS3      : origin = 0x00F000, length = 0x001000
       RAMGS4      : origin = 0x010000, length = 0x001000
       RAMGS5      : origin = 0x011000, length = 0x001000
       RAMGS6      : origin = 0x012000, length = 0x001000
       RAMGS7      : origin = 0x013000, length = 0x001000
    //TW   RAMGS8      : origin = 0x014000, length = 0x001000
    //TW   RAMGS9      : origin = 0x015000, length = 0x001000
       RAMGS10     : origin = 0x016000, length = 0x001000
       RAMGS11     : origin = 0x017000, length = 0x001000
       RAMGS12     : origin = 0x018000, length = 0x001000
       RAMGS13     : origin = 0x019000, length = 0x001000
       RAMGS14     : origin = 0x01A000, length = 0x001000
       RAMGS15     : origin = 0x01B000, length = 0x001000
      
       CPU2TOCPU1RAM   : origin = 0x03F800, length = 0x000400
       CPU1TOCPU2RAM   : origin = 0x03FC00, length = 0x000400
    }


    SECTIONS
    {
       codestart        : > BEGIN,     PAGE = 0
       ramfuncs         : > RAMM0      PAGE = 0
      
    #ifdef __TI_COMPILER_VERSION__
       #if __TI_COMPILER_VERSION__ >= 15009000
        .TI.ramfunc : {} > RAMM0,      PAGE = 0
       #endif
    #endif  
      
    //TW:
    //   .text            : >>RAMM0 | RAMD0 |  RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3 | RAMLS4,   PAGE = 0
       .text            : >>RAMGS8 | RAMGS9   PAGE = 0

       .cinit           : > RAMM0,     PAGE = 0
       .pinit           : > RAMM0,     PAGE = 0
       .switch          : > RAMM0,     PAGE = 0
       .reset           : > RESET,     PAGE = 0, TYPE = DSECT /* not used, */

       .stack           : > RAMM1,     PAGE = 1
       .ebss            : > RAMLS5,    PAGE = 1
       .econst          : > RAMLS5,    PAGE = 1
       .esysmem         : > RAMLS5,    PAGE = 1
       Filter_RegsFile  : > RAMGS0,    PAGE = 1

       ramgs0           : > RAMGS0,    PAGE = 1
       ramgs1           : > RAMGS1,    PAGE = 1
      
       /* The following section definitions are required when using the IPC API Drivers */
        GROUP : > CPU1TOCPU2RAM, PAGE = 1
        {
            PUTBUFFER
            PUTWRITEIDX
            GETREADIDX
        }
       
        GROUP : > CPU2TOCPU1RAM, PAGE = 1
        {
            GETBUFFER :    TYPE = DSECT
            GETWRITEIDX :  TYPE = DSECT
            PUTREADIDX :   TYPE = DSECT
        } 
     
    }

    /*
    //===========================================================================
    // End of file.
    //===========================================================================
    */

    Can you reproduce this behavior? Is there a way to avoid that?

    Best regards,
    Thomas.

  • Hi Thomas,
    I was not able to reproduce the issue. I used the blinky_cpu01 example for F2837xD and there was no ESTOP as main before or after your linker command file modifications. Please let me know the exact project you used (including the version of the example) to make sure.

    Thanks
    ki
  • Hi ki,

    I used the project from here:

    C:\ti\controlSUITE\device_support\F2837xD\v210\F2837xD_examples_Cpu1\blinky

    Today I brought in a second computer for verification. And I found that besides the changed linker command file it needs both CPUs to be selected when starting the debug session (I learned from the C2000 multi day workshop that normally just CPU1 should be selected; thanks for putting that material online so that I can do the whenever I have some time left!). Also while debugging the ESTOP0 disappears as soon as I stop CPU2. Now I think what we see here is the SW breakpoint of the second core. Do you agree?

    I have to say that I'm quite new to this MCU, and decided for start to ignore the second core. Therefore I left everything to it's default settings. It seems that the handling of both cores should be the next thing I look into.

    Best regards,

    Thomas.

  • Thomas78173 said:
    C:\ti\controlSUITE\device_support\F2837xD\v210\F2837xD_examples_Cpu1\blinky

    Yes, I am using the same project then

    Thomas78173 said:
    both CPUs to be selected when starting the debug session (I learned from the C2000 multi day workshop that normally just CPU1 should be selected; thanks for putting that material online so that I can do the whenever I have some time left!).

    Are you loading and running both CPUs with the above example? Can you provide, in detail, the exact steps you are doing so i can copy it in my environment?

    Thanks

    ki

  • Nevermind my last request. I can reproduce the issue.

    the ESTOP appearance is due to the code being in shared memory and the auto-run to main option is enabled. As John mentioned earlier, when auto-run to main is enabled, it will set a SW breakpoint at the start of main (ESTOP). What is happening in your scenario is this:

    1) debug session is launched and same code is loaded to both CPUs
    2) breakpoint is set at main for CPU1 and CPU1 is executed
    3) CPU1 halts at main and breakpoint is cleared
    4) breakpoint is set at main for CPU2 and CPU2 is executed
    5) CPU2 never reaches main (breakpoint (ESTOP) is never cleared)
    6) CPU1 is not aware of the breakpoint set for CPU2 so when you look at the disassembly view at main, you will see the ESTOP set for CPU2 (the opcode replacement will only be done if the disassembly view is in the same context as CPU that the breakpoint was set for)

    7) When CPU2 is halted, the breakpoint is cleared and ESTOP goes away for the disassembly view for CPU1

    The above can be confirmed by disabling the auto-run to main for both CPUs and then when you launch a debug session for both cores, both should be halted at the code entry point. If you check the disassembly view for CPU1, you will not see an ESTOP. The select CPU2 and run it via 'Run -> Go Main'. Debugger will set a breakpoint for CPU2 at main and run. CPU2 will continue running since it cannot reach main. If you go to the disassembly view of CPU1, you will see the ESTOP appear at main. This ESTOP is the SW breakpoint from CPU2.

  • Also note that the same code is being loaded twice (the load for the second CPU is overwriting the same code at the same global shared location that was loaded by CPU1)

  • Thanks to everybody for helping me in this issue.