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
Reply by moschops●January 12, 20082008-01-12
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
Reply by Jack Klein●January 11, 20082008-01-11
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.
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