Bizarre TigerSHARC memory behaviour in VDSP JTAG session

Debugging a TigerSHARC on a VMetro C43 quad TigerSHARC board, I 
encountered what seemed to be a most odd problem.

I'm running a debug session using VDSP across a JTAG. I put the program 
on hold and open a memory window, and look at memory location 0x180000, 
which I believe to be TigerSHARC internal memory. Hopefully some registers.

The values make no sense, and more to the point when I scroll up or 
down, they change. The numbers all change (they're all identical after 
0x180000 for quite some way) to identical nonsensical values, as i 
scroll up and down, or resize the window. The program is on hold, via 
the mighty F5 key.

Has anyone seen this before, or something like it? ANy ideas as to what 
it means?

I created a few variables to instructed them to be loaded with values 
taken from this memory before I pause it, and the values in these 
variables agree with the values in the memory window at the point of 
pausing. These variables thankfully hold their value when the values in 
the window change.

'Chops

On Fri, 11 Jan 2008 15:28:37 +0000, moschops <moschop@madasafish.com>
wrote in comp.dsp:

I don't know anything at all about the TigerSHARC, but...

> Debugging a TigerSHARC on a VMetro C43 quad TigerSHARC board, I 
> encountered what seemed to be a most odd problem.
> 
> I'm running a debug session using VDSP across a JTAG. I put the program 
> on hold and open a memory window, and look at memory location 0x180000, 
> which I believe to be TigerSHARC internal memory. Hopefully some registers.

Exactly why are you looking at memory and expecting it to behave a
certain way when you have no idea what it is?  Why don't you read the
data sheet for the DSP and find out exactly what it is?

> The values make no sense, and more to the point when I scroll up or 
> down, they change. The numbers all change (they're all identical after 
> 0x180000 for quite some way) to identical nonsensical values, as i 
> scroll up and down, or resize the window. The program is on hold, via 
> the mighty F5 key.

How do you know that the values make no sense, when you don't know
what they are supposed to be?  If you don't know what registers these
are, or even know for sure that they are registers, how do you know
what values you should expect?

> Has anyone seen this before, or something like it? ANy ideas as to what 
> it means?

Stopping the execution of code on the processor quite possible does
not halt the operation of hardware peripherals on the chip, unless
your processor offers that capability and you have told your debugger
to do that.

If one of the registers is part of a timer, for example, it would
continue changing at the same rate whether the program is halted or
not.  Every time you refreshed the debugger's display, it is most
likely reading the new current value of the registers from the chip.

> I created a few variables to instructed them to be loaded with values 
> taken from this memory before I pause it, and the values in these 
> variables agree with the values in the memory window at the point of 
> pausing. These variables thankfully hold their value when the values in 
> the window change.

On the processors and DSPs that I use, if I have hardware registers
open in a debugger window I expect the values of at least some of them
to change when I refresh the display.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Jack Klein wrote:

> Exactly why are you looking at memory and expecting it to behave a
> certain way when you have no idea what it is?  Why don't you read the
> data sheet for the DSP and find out exactly what it is?
> 

What makes you think I don't know what they're meant to be? I do know 
what they're meant to be. They're internal registers and the reported 
values make no sense, and for tens of thousands of memory locations they 
all have identical nonsensical values.

'Chops

Yes, 0x180000 is the memory space for internal registers, however the 
TigerSharc cannot access it's own registers using memory addresses, only 
other TigerSharcs on the bus can in multiprocessor space.  This is a 
different from SHARC, which allowed memory based register access.

Even in the simulator you get undefined values when you open a memory window 
on this space.

-------
Ron Huizen
BittWare

P.S. I was tempted to tell you if you were using a BittWare TigerSHARC board 
instead of the one you mention, it would have worked ;-)



"moschops" <moschop@madasafish.com> wrote in message 
news:qMWdnfgdxf5zFxranZ2dnUVZ8hydnZ2d@brightview.com...
> Debugging a TigerSHARC on a VMetro C43 quad TigerSHARC board, I 
> encountered what seemed to be a most odd problem.
>
> I'm running a debug session using VDSP across a JTAG. I put the program on 
> hold and open a memory window, and look at memory location 0x180000, which 
> I believe to be TigerSHARC internal memory. Hopefully some registers.
>
> The values make no sense, and more to the point when I scroll up or down, 
> they change. The numbers all change (they're all identical after 0x180000 
> for quite some way) to identical nonsensical values, as i scroll up and 
> down, or resize the window. The program is on hold, via the mighty F5 key.
>
> Has anyone seen this before, or something like it? ANy ideas as to what it 
> means?
>
> I created a few variables to instructed them to be loaded with values 
> taken from this memory before I pause it, and the values in these 
> variables agree with the values in the memory window at the point of 
> pausing. These variables thankfully hold their value when the values in 
> the window change.
>
> 'Chops