Code corruption on XS1-G04B-FB144-C4 / XTAG-2

[TjBordelon]

I'm trying to track down what appears to be corrupt opcodes appearing in my code. Opcodes are getting nuked and it seems related to whether or not I'm hitting breakpoints in the debugger (or even just stopping the debugger prior to the trouble spot)

I tried purposefully writing to one of the bug's favorite spots: 0x1057a-- and get a memory exception. This is good! That means I might not be me causing this. I even commented out most all of my code and got down to 1 core running and it still happens.

I'm also seeing evidence that the JTAG/Debugger is writing code to the XCORE to do it's debugging duties, and it likes to write to this location. I haven't proven it yet, but it really appears that the debugger is corrupting code. This is pure evil if it is true.

Do any of you guys ....

1) See this sort of thing?

2) Know where I can find info on the memory map and whether there is sort of a protection mechanism that protects code-- I think there is, but can't find info on it...

3) Know if there is a good way to turn on logging in such a way to catch writes by the JTAG itself? I want to bust it red handed.

4) Know why if you click in the debug context (select different tiles/cores) the memory window doesn't seem to change? I thought each tile had it's own 64k. This isn't working as I'd expect.

At this stage I think this is further fallout from the fact that the debugger on multicore processors is buggy with knowing where code is actually located (the disassembly window likes to lie alot). It seems to get confused and doesn't know where code actually is. My hypothesis at the moment is that it might be confused about where it should write scratchpad stuff during the session and it's the culprit.

Haven't proven it yet... any info is greatly appreciated!

[Bianco]

The SRAM is mapped at 0x00010000 to 0x0001FFFF and there are no protections.

[TjBordelon]

The SRAM is mapped at 0x00010000 to 0x0001FFFF and there are no protections.

Ok, this is very important to know. Thanks. Do you happen to know how the memory window decides which tile's context to use? It seems to not follow the highlighted thread in the debug window, and seems random. I can never figure out how to tell (or change) what tile I'm looking at.

It's interesting in my testing that trying to do a :

unsigned int *ptr = (unsigned int*) 0x1057a;
*ptr = 0xFEEFEE;

...dies with a memory exception.

What I am seeing seems to be summed up in this:

1) If I hit a breakpoint in tile2 followed by a breakpoint in tile 0, memory near the tile0 bp seems to have an illegal instruction.

2) If I skip the breakpoint in tile2 and just leave the bp in tile 0 it works.

3) If I put a breakpoint after the bad spot, it gets past it just fine.

My conclusion thus far is that breakpoints cannot be placed on more than one core, or very bad things happen when the 2nd core gets a breakpoint. This seems backed up by plenty of testing.

[Bianco]

It's interesting in my testing that trying to do a :

unsigned int *ptr = (unsigned int*) 0x1057a;
*ptr = 0xFEEFEE;

Try a word (4-byte) aligned address like 0x1057c

[TjBordelon]

Try a word (4-byte) aligned address like 0x1057c

You're so modest... and right :) How embarrassing. My brain shuts down when 5 problems attack at once.

So with that, I think I have a picture forming on my G4 situation and most all my issues. Skimming the forums, it appears the G4 is a very old part compared to the L series.

Unfortunately, it also appears this part is not entirely supported by the tools either. Or if it was intended, testing has fallen by the wayside and lands on poor saps like me.

My adventures have taken me through broken debug windows, memory windows, breakpoints that don't work, code corruption, incompatible links. Why in the world wasn't there a release note on this??? I would have designed an L part into the system. Maybe two. Gee thanks.

I'm now able to work completely fine-- the secret to having an IDE that actually works... drum roll...

Do not put breakpoints on >1 core. Only debug one at a time.

Between your "touche" and this, I'm back up and running.