TMS570 Breakpoint and CPU Self Test

Takashi.H

Other Parts Discussed in Thread: TMS570LS3137, HALCOGEN

Hi there.

I'm new to Hercules and Embedded Development. I'm not good at English, Please forgive the poor English of the question.
I'm faced with a problem of CPU Self Test and breakpoint.

I use
・CCS5.5
・TMS570LS3137 HDK
・HALCoGen 04.05.02
・XDS100v2

Q1. In my environment, software breakpoint don't work.
Is it beacuse my program is running from Flash?
(I think that Running from Flash is default Code generated by HALCoGen)

Q2. I tried to test CPU Self Test.
    I Checked [Enable CPU Self test] in HALCoGen.([Enable CPU Self test]：SAFATY INIT →Self test Enable)
    I didn't add any code to _c_int00 function.
    I just made test code in main(). The test code is

void main(void)
{
    unsigned int i =0;
    printf("enter main\n");
    hetInit();                                 // Light HDK's LED
    while(1)
    {
        i++;
    }
}

I set a H/W beakpoint on [printf("enter main\n")] line.
I built project and debug, some problems occured.

・did not stop at H/W beakpoint.
・did not work printf("enter mian\n") (to CCS Consle)
・HDK's LED is Lighted.(← [hetInit()] line is excuted.)
・After a while, When I Clicked Suspend(Alt + F8), Current Instruction is [i++] line.

WHY did this problems occur?

Note: I tested to uncheck [Enable CPU Self test] and did same.
・stopped H/W breakpoint
・worked printf ("enter mian\n")
・HDK's LED is Lighted.

Q3.I would like to do:
1. Before Application program is starting, excute 24 intervals self test(24 intervals self test need to be done in _c_int00)
2. After excuting 24 intervals self test, go to Application program.

Should I add or modify code generated by HALCoGen?
Should I save Context?(TRM 8.2.2)

I'm sorry so many questions and poor English.

over 8 years ago

0 Anthony F. Seely over 8 years ago

TI__Guru 68920 points

Hi Takashi,

Your English is very very good ;)

Breakpoints from Flash need to be hardware breakpoints, meaning that they utilize an address comparator in the debug logic attached to the CPU to stop the CPU when there is a compare match. For this reason, they are limited in number.

They also get reset whenever the CPU LBIST is executed. So this would explain why you are having difficulty stopping at main() if the LBIST is executed prior to main().

I don't think there is any issue in what you are trying to do but you will just need to understand that the breakpoint at main() gets cleared when the self test is run so you won't stop at main() but as you observed you will execute main().

-Anthony

0 Takashi.H over 8 years ago in reply to Anthony F. Seely

Prodigy 160 points

Thank you for your reply!

OK, I understood that when LBIST is executed, breakpoints are cleared.

sorry, some questions,

・Is there a way to reset breakpoints automatically after CPU reset caused by LBIST completion?

I think that we can't debug main function (= my application) using breakpoint when LBIST is enabled.

In my opinion, best way to reset breakpoins automatically is using GEL file.( OnResetDetected() or OnReset() and GEL_HWBreakPtAdd() )

Can it(Using GEL) do?

Otherwise, Access to CP14 coprocessor help us?

・Why did not execute printf only when LBIST is enabled?

I'm concerned that there are codes which are not executed (like a printf in case of my test code) when LBIST is enabled.

0 Anthony F. Seely over 8 years ago in reply to Takashi.H

TI__Guru 68920 points

Hi Takashi,

Takashi.H said:
・Is there a way to reset breakpoints automatically after CPU reset caused by LBIST completion?

Good question. I haven't investigated this before. CCS isn't setup to do this automatically but as you proposed maybe some of the GEL hooks can help.

My instinct though is that it wouldn't be fast enough through JTAG to have the host PC detect the reset, then trigger the GEL to halt the CPU, then set the breakpoints again. I think the target would probably normally already be past main if you just try this.
So my guess is that you would need some helper code in the application that induced extra delay if you wanted this behavior.

Another option as you mention might be to try to use the CPU to save & restore it's breakpoint registers to/from RAM on both sides of LBIST but what I don't know here is whether there is an ownership bit covering these breakpoints that would be preventing the CPU from saving/restoring them. You would probably need to carefully study the CPU manual and the coresight debug manuals to see if there is some scheme that you could make use of.

Takashi.H said:

・Why did not execute printf only when LBIST is enabled?

I'm concerned that there are codes which are not executed (like a printf in case of my test code) when LBIST is enabled.

Don't be concerned. The TI C compiler implementation of C IO uses breakpoints so the same reason you don't stop on main() is the same reason you don't stop in C IO.

You *can* do something about this though - if you implement a device driver that directs the C IO to a UART or other device instead of through the debugger breakpoint mechanism. The compiler manual explains how to do this.

0 Takashi.H over 8 years ago in reply to Anthony F. Seely

Prodigy 160 points

Thanks your reply and Sorry for the late reply.(><)

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570 Breakpoint and CPU Self Test