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.

TMDSDOCKH52C1: Hardware breakpoint

Part Number: TMDSDOCKH52C1
Other Parts Discussed in Thread: CONTROLSUITE

Hi team,

Good day.

I am posting this query on behalf of our customer. Kindly help us with your expertise on the part.

" I bought a F28M35 control card. I studied the TI workshop about it ( and I'm basing my code in its lab and also the examples found in Control Suite. In the workshop labs, we add the memory map file (with the extension .cmd). This memory file loads the code into the flash. In the workshop labs, we add the memory map file (with the extension .cmd). This memory file loads the code into the flash. However, when I'm debugging code in the flash, I'm restricted to hardware breakpoints. I would like to load it in RAM. I loaded the RAM map file in Control Suite. When the code gets bigger, it shows the message saying that the code won't fit into available memory. I changed the memory map file to allocate more space for the text session.

It builds ok. Then I start debugging the M3 CPU, connect the C28 CPU and load this code into the C28 CPU. When this code loads, it doesn't stop in main It starts running automatically but it never gets inside the main function. The memory map is ok, it builds, but I think it might be related to the problem. The big issue is the C28 CPU starting to run and never entering the main function."


  • Hi Carlo,

    Couple of changes that you need in the linker command (.cmd) file.

    1. There should be OR between RAML0L1 and RAMS0 for the .text section

    .text            : > RAML0L1 | RAMS0 | RAMS1,    PAGE = 0

    2. Also, since you are loading to RAM, there is no need of copying the .TI.ramfunc section. You can have the following statement instead of load and run from RAM.

    .TI.ramfunc : {} > RAMM0,      PAGE = 0

    Did you try to single step through the source code after loading the program? .

    Also , you can refer the attached cmd file. This is also included in ControlSuite in the folder "C:\ti\controlSUITE\device_support\f28m35x\v220\F28M35x_common\cmd".


    Best Regards


  • Hi Siddharth,

    Thank you for your response. Our customer has implemented the modifications you suggested regarding the linker command file, still, they're having no success in running the code properly.

    Attached is the main file, the linker command file, and a screenshot. According to the customer, they have initiated the debug session with the M3 core, connect the C28 CPU, build the C28 code and then load the C28 binary. In line 52 of main_C28.c there is a call to a subroutine defined in another source file. When they comment this line and load the code, the debugger stops at the beginning of the main function, as expected. When they uncomment this line, build and load the code, it seems that it doesn't enter the main function. The debugger view shows that the code is running, as in the screenshot.


     * main.c
    #include <string.h>
    #include "DSP28x_Project.h"     // Device Headerfile and Examples Include File
    #include "F28M35x_CpuTimers.h"
    #include "./device/device.h"
    #include "./include/nitee/Equipment.h"
    extern Uint16 RamfuncsLoadStart;
    extern Uint16 RamfuncsLoadSize;
    extern Uint16 RamfuncsRunStart;
    Uint16 indication_led_count;
    void Equipment_init();
    interrupt void adc1_isr(void);
    Equipment *equip;
    int main(void)
    	// Init C28 core
    	// Copy time critical code and Flash setup code to RAM
    	// This includes the following functions: InitFlash();
    	// The  RamfuncsLoadStart, RamfuncsLoadSize and RamfuncsRunStart
    	// symbols are created by the linker. Refer to the device .cmd file.
    	// memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (size_t)&RamfuncsLoadSize);
    	// Allows writing to protected registers
    	// Defining an address for the ISR to be called
    	PieVectTable.ADCINT1 = &adc1_isr;
    	EINT;  // Enable Global interrupt INTM
    	ERTM;  // Enable Global realtime interrupt DBGM
    	// Init peripherals
    	// Revokes permition to write protected registers
    	// Init Equipment data structure
    	// equip = Equipment_init();
    	return 0;
    interrupt void adc1_isr(void)
    	PROFILE_LED = 1;
    	if(indication_led_count++ > 6250)
    		INDICATION_LED ^= 1;
    		indication_led_count = 0;
    	PROFILE_LED = 0;
    	Adc1Regs.ADCINTFLGCLR.bit.ADCINT1 = 1;
    	PieCtrlRegs.PIEACK.all = PIEACK_GROUP1;

    Your further assistance is appreciated.


  • Hi Carlo,

    Looks like the "Equipment_init()" is corrupting some memory which is causing this behavior. Can you request the customer to single step through the code without trying to run to main function?  You can also ask them to review the map file and see if the placement of the sections is correct.

    Best Regards


  • Hi Siddharth,

    Here is the response we received from the customer:

    I tried to step through the code without running to main function as suggested, I hope I proceeded as you expected. Please let me know if I'm mistaken. These are the observations I made:

    When I configure the debugger to run to _args_main:

    If the line equip = Equipment_init(); is commented out, the debugger breaks at the beginning of the _args_main() function in args_main.c, as expected. After resuming the code execution, the LED in the control card blinks, showing that the application is running.

    If such line is not commented out, however, the code runs free, without ever stopping at _args_main() or anywhere else. It is the same unexpected behavior. The LED in the control card doesn't blink.

    When I configure the debugger to run to _c_int00:

    If the line equip = Equipment_init(); is commented out, the debugger doesn't break anywhere in the code, but the LED blinks, showing that the application is running. If I set a breakpoint inside the adc1_isr function, the debugger runs into it. The device behaves as I expected.

    If such line is not commented out, however, no LEDs blink. If I set a breakpoint inside the adc1_isr function, the debugger never runs into it. When I suspend the debugger, it shows a message 'Break at address "0x3fefa6" with no debug information available, or outside of program code'.

    Another observation I made: I opened the Memory Browser and searched for the main symbol in the program section, as in the screenshot. When the problematic function call is commented out, the main function is located at the address 0x8D1D. According to the memory map, this is inside the RAML0L1 region. However, when the call to Equipment_init() is not commented out, the main symbol is at address 0xD051, which is in the RAMS1 region. I wonder if this is related to the problem I'm having.

    Are these informations useful? Would you have any ideas on how should I proceed to solve this problem? Is there any more information that I could provide or tests that I could run?

    I deleted the line 17, which contains "void Equipment_init();". The function I'm calling is, in fact, defined in another source code and declared in a header file. I can't share them, unfortunately, but I don't think they contain anything that could corrupt memory. I executed them in other platforms and no problems were observed. They just contain standard C code.


  • Hi Carlo,

    Thanks for the detailed analysis.

    You mentioned that when the call to Equipment_init() is not commented out, the execution doesn't even reach the main function. This indicates that there is some problem during initialization . Does the Equipment_init() function has any global variables? Can you figure out where it gets stuck during the execution of the _c_int00 function. I think it might be getting stuck during the auto initialization of the global variables.

    Best Regards