• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 950 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.

Hardware watchpoint issue

Clement FR
Genius 4750 points


Hello everyone,

I'm on CCS 6.0.0.00098, using the EVMC6678 as a target. JTAG probe is XDS560v2 STM.

The issue was also reproduced with CCS 5.5.

In shared memory I have a global structure or variable.

In this structure I have a field I want to monitor as a hardware watchpoint to see which core writes to it and when.

In the breakpoint view I click on new -> hardware watchpoint and then I type :

mystruct.myfield and I select "Write".

The hardware watchpoint is valid at address 0x0C000000

When in my code I do mystruct.myfield = 123; (let's assume myfield is an unsigned int)
the watchpoint is not triggered.

Even with a simple variable it doesn't work.

Any idea why?

Thank you,

Clement

PS : find attached a project to reproduce the issue.

Set a 'write' hardware watchpoint on var or hi.word1 and see that it is not triggered on lines 21 or 25 but only on line 27 during the prinft (which is strange because it's a read).

2260.testwatchpoint.zip

  • 0
    TI__Guru**** 171309 points

    Clement,

    I suspect the original variables are stored in registers during the execution of main(), modified and only written back to memory before executing the printf() - the watchpoint inspects the address of the memory bus being accessed, therefore the register access is "invisible" to it.

    However, I will still do some more tests to prove my theory. Let me get back to you on that.

    Regards,

    Rafael

     

  • 0 in reply to desouza
    TI__Guru**** 171309 points
    2014-08-12 15h31_03.mp4

    Clement,

    I did some tests on your example code and found out the watchpoint is taking some time to react and halt the target.

    I modified your testcase as shown below and I found out the target is halted inside the delay loop instead of the printf() call. I measured the number of  profile clock showed something around 20 cycles  

    int main(void) {
	
	unsigned int count_delay;
	printf("hello world\n");

	hi.word1 = 123;
	for (count_delay = 40; count_delay > 0; count_delay--);

	hi.word1++;
	for (count_delay = 40; count_delay > 0; count_delay--);

(...)

    Looking at the watchpoint properties I can spot it is "imprecise" by nature. What it means is it takes some cycles to react and halt the target - which is usually a property of the device itself.

    I will do some more testing on this testcase and see if I find something that indicates otherwise. I will report back if I find something different, ok?

    Regards,

    Rafael

     

     

  • 0 in reply to desouza
    Genius 4750 points

    Rafael,

    Thank you for your work on this.

    Behind this test case I have a more specific issue which is :

    - I have a memory alias of the shared memory (the logical address is in the 0xA1000000 range (seen by the CPU) and is aliased to physical memory 0x0C00000 (Multicore shared memory) on the C6678.

    - At 0xA1002000 I have placed a structure.

    - During execution I have noticed that somebody is writing garbage at this address after I init it with 0. My aim is to find out who is this somebody. (it looks like a buffer overflow or something)

    - I set a watchpoint at this address.

    - Starting from main, I hit run. The target stops (due to the watchpoint) when my code do the initialization of the structure, which was expected).

    - I hit run again and nothing happens, the watchpoint is not triggered.

    - I hit pause, look at the address and see that the value is no longer 0 but something like 0xF2BA56CD (pure garbage, not even an address). And the watchpoint did NOT catch the write and I don't know what/who is causing it.

    My question is: is it somehow related to the memory aliasing ?

    I don't know if the hardware watchpoint use the 'cpu' view of memory or the physical one.

    Regards,

    Clement