0

I'm running the TRACE32 debugger on a tc27x Infineon CPU

I'm chasing a stack corruption, I know that some Task or ISR is overwriting a specific stack address with a wrong value. The address is 0x7000c0ec and the value is 0x41000000, I'd like to set a conditional breakpoint that only stops when someone performs a write operation in such address and with such or a greater value.

But I don't know the specific syntax to fill the Condition text box; from my gdb background I expected something like:

*(0x7000c0ec) == 0x41000000

enter image description here

Cena
  • 3,316
  • 2
  • 17
  • 34
Alberto Riera
  • 49
  • 1
  • 9
  • Hello Alberto, your condition should work, can you elaborate your problem? Also I suggest to use `/Onchip` + `/Write` + `/Data` breakpoints instead of `/CONDition` if your CPU supports them. – dev15 Jul 11 '19 at 13:24
  • Just for clarification: Is `0x7000c0ec` overwritten or `*0x7000c0ec`? – dev15 Jul 11 '19 at 13:29
  • Actually I'm using a watchpoint in such address write, the problem is that I only want to stop when the value written is an specific one. The overwritten is the content inside such 0x7000c0ec. And when I use *(0x7000c0ec) I get an error – Alberto Riera Jul 11 '19 at 13:33
  • Can you post the error message? Do you set the breakpoint using a command or using the GUI? – dev15 Jul 11 '19 at 13:49
  • Hi, actually I dont have the error anymore, but I never see the breakpoint to stop even when actually the memory location is writeen with the expected value – Alberto Riera Jul 12 '19 at 09:27
  • Can you try `Break.Set D:0x7000c0ec /Onchip /Write /DATA.Long 0x41000000`? Or `Break.Set D:0x7000c0ec /Onchip /Write /CONDition Data.Long(D:0x7000c0ec)==0x41000000`? If it doesn't work: Can you post the output of `PRINT Data.Long(D:0x7000c0ec)` after the error occurred? – dev15 Jul 12 '19 at 11:39
  • I've tried but it does not work either. The trap occurs , the memory is already with the vcalue content and the breakpoint has not stopped the cpu. I've attached a picture in the first question – Alberto Riera Jul 15 '19 at 06:38
  • Onchip breakpoints are only focused on the core's view. So have you set `Break.Set D:0x7000c0ec++3 /Onchip /Write /DATA.Long 0x41000000` on all cores which have access to that memory? (In an SMP session that happens automatically, but if you have a separate GUI for each core (AMP) you have to set the breakpoint in each GUI (or use InterCom for that)). Could it be that some DMA or the HSM alters the memory? – Holger Jul 15 '19 at 11:23
  • And definitively use `Break.Set D:0x7000c0ec++3 /Onchip /Write /DATA.Long 0x41000000` instead of just `Break.Set D:0x7000c0ec /Onchip /Write /DATA.Long 0x41000000` otherwise you might miss 8-bit or 16-bit writes to that memory. – Holger Jul 15 '19 at 11:28
  • Now it works, but is curious because when the CPU stops and I review carefully the registers status no one is writing such value, but the address really holds such value. Indeed we are using two CPUs and DMA as well so maybe you're right and that's the cause. But is weird that if it is a DMA issue all the memory around shouldd be corrupted and not only such specific address, the rest of the stack seems to be right. – Alberto Riera Jul 16 '19 at 13:56

0 Answers0