Anyone ever seen this DC debugging error?
I'm using an RCM3200 with DC8.61. When I select "Code and BIOS in
flash", I can debug (RST28's) no problem. When I select "Code and
BIOS in flash, run in ram", however, DC will often crash
with "System Nak - reason: 02 type: 01, subtype: 01". After
clicking through a bunch of these, it'll eventually show a timeout
while debugging error, and then the "NAK" error with subtype 0f. I
don't know if it's relevant or not, but it appears to happen mostly
when I'm accessing the filesystem I have defined in RAM (BBRAM, that
is, when "run in RAM" is selected).
It's just strange that this only appears when "run in RAM" is
selected.
Thanks,
Darrin
system nak?
Started by ●July 27, 2004
Reply by ●July 28, 20042004-07-28
Well, I partially figured out what was going on here: the issue was
symptomatic of stack overflow, and while that wasn't it, it was
something similar. In my program, I've got an xmem "pointer" that
is initialized within a GLOBAL_INIT:
:
#GLOBAL_INIT {point_ext_xmem = xalloc(MY_SIZE); }
:
When "code and bios in flash" compile is chosen, this works fine and
provides a pointer to RAM (fast RAM, presumably), in the 0x80000-
0xBFFFF range. When "code and bios in flash, run in RAM" is chosen,
however, this "pointer" has 0xFFFFFFFF in it at main(). Since I use
this "pointer" to access xmem later, some sort of overflow was
apparently happening during root2xmem and xmem2root calls.
So, does anyone know of any restrictions regarding xalloc's (or any
other function calls, for that matter) in GLOBAL_INIT's when "run in
RAM" is selected on the RCM3200? It appears to not work. When I
changed this xalloc call to be done within the scope of the program
to init this pointer, all works fine with "run in RAM" compile
selected.
2. Another question: I was looking at Scott's post #19616, and the
#18759 thread regarding the RAM mappings when "code and bios in
flash" and "code and bios in flash, run in RAM" is selected, and
this seems to make sense. What I can't tell, however, is if the
code size is less than 512kB (which means the fast RAM is not full),
is the remainder of the fast RAM IC made available for RAM
allocations, or is it treated as though it were "flash", and
therefore xalloc's would start at physical address 0x80000 (where
the 256kB bbRAM IC is located)? I'm asking because I expected this
xalloc result to be in the range of 0x80000-0xBFFFF (which it is
when "code and bios in flash" is chosen), but it's returning a value
0x7xxxx (above my code but presumably within the 512kB fast RAM
space).
Sorry for the questions, but info on the RCM3200 seems hard to come
by, unless I'm just not looking in the right place.
Thanks,
Darrin
--- In rabbit-semi@rabb..., "icc_thewoodlands"
<dhansen@i...> wrote:
> Anyone ever seen this DC debugging error?
>
> I'm using an RCM3200 with DC8.61. When I select "Code and BIOS in
> flash", I can debug (RST28's) no problem. When I select "Code and
> BIOS in flash, run in ram", however, DC will often crash
> with "System Nak - reason: 02 type: 01, subtype: 01". After
> clicking through a bunch of these, it'll eventually show a timeout
> while debugging error, and then the "NAK" error with subtype 0f.
I
> don't know if it's relevant or not, but it appears to happen
mostly
> when I'm accessing the filesystem I have defined in RAM (BBRAM,
that
> is, when "run in RAM" is selected).
>
> It's just strange that this only appears when "run in RAM" is
> selected.
>
> Thanks,
> Darrin
symptomatic of stack overflow, and while that wasn't it, it was
something similar. In my program, I've got an xmem "pointer" that
is initialized within a GLOBAL_INIT:
:
#GLOBAL_INIT {point_ext_xmem = xalloc(MY_SIZE); }
:
When "code and bios in flash" compile is chosen, this works fine and
provides a pointer to RAM (fast RAM, presumably), in the 0x80000-
0xBFFFF range. When "code and bios in flash, run in RAM" is chosen,
however, this "pointer" has 0xFFFFFFFF in it at main(). Since I use
this "pointer" to access xmem later, some sort of overflow was
apparently happening during root2xmem and xmem2root calls.
So, does anyone know of any restrictions regarding xalloc's (or any
other function calls, for that matter) in GLOBAL_INIT's when "run in
RAM" is selected on the RCM3200? It appears to not work. When I
changed this xalloc call to be done within the scope of the program
to init this pointer, all works fine with "run in RAM" compile
selected.
2. Another question: I was looking at Scott's post #19616, and the
#18759 thread regarding the RAM mappings when "code and bios in
flash" and "code and bios in flash, run in RAM" is selected, and
this seems to make sense. What I can't tell, however, is if the
code size is less than 512kB (which means the fast RAM is not full),
is the remainder of the fast RAM IC made available for RAM
allocations, or is it treated as though it were "flash", and
therefore xalloc's would start at physical address 0x80000 (where
the 256kB bbRAM IC is located)? I'm asking because I expected this
xalloc result to be in the range of 0x80000-0xBFFFF (which it is
when "code and bios in flash" is chosen), but it's returning a value
0x7xxxx (above my code but presumably within the 512kB fast RAM
space).
Sorry for the questions, but info on the RCM3200 seems hard to come
by, unless I'm just not looking in the right place.
Thanks,
Darrin
--- In rabbit-semi@rabb..., "icc_thewoodlands"
<dhansen@i...> wrote:
> Anyone ever seen this DC debugging error?
>
> I'm using an RCM3200 with DC8.61. When I select "Code and BIOS in
> flash", I can debug (RST28's) no problem. When I select "Code and
> BIOS in flash, run in ram", however, DC will often crash
> with "System Nak - reason: 02 type: 01, subtype: 01". After
> clicking through a bunch of these, it'll eventually show a timeout
> while debugging error, and then the "NAK" error with subtype 0f.
I
> don't know if it's relevant or not, but it appears to happen
mostly
> when I'm accessing the filesystem I have defined in RAM (BBRAM,
that
> is, when "run in RAM" is selected).
>
> It's just strange that this only appears when "run in RAM" is
> selected.
>
> Thanks,
> Darrin
Reply by ●July 28, 20042004-07-28
At 02:03 PM 7/28/2004, you wrote:
>So, does anyone know of any restrictions regarding xalloc's (or any
>other function calls, for that matter) in GLOBAL_INIT's when "run in
>RAM" is selected on the RCM3200? It appears to not work. When I
>changed this xalloc call to be done within the scope of the program
>to init this pointer, all works fine with "run in RAM" compile
>selected.
You can not guarantee the order of GLOBAL_INIT's. Probably the xmem init is
set up in a later GLOABL_INIT. I avoid GLOBAL_INIT's at all costs. >2. Another question: I was looking at Scott's post #19616, and the
>#18759 thread regarding the RAM mappings when "code and bios in
>flash" and "code and bios in flash, run in RAM" is selected, and
>this seems to make sense. What I can't tell, however, is if the
>code size is less than 512kB (which means the fast RAM is not full),
>is the remainder of the fast RAM IC made available for RAM
>allocations, or is it treated as though it were "flash", and
>therefore xalloc's would start at physical address 0x80000 (where
>the 256kB bbRAM IC is located)? I'm asking because I expected this
>xalloc result to be in the range of 0x80000-0xBFFFF (which it is
>when "code and bios in flash" is chosen), but it's returning a value
>0x7xxxx (above my code but presumably within the 512kB fast RAM
>space).
Yes, it will use the fast RAM first, then the slow RAM. There was a
reference in 7.x to some upcoming bb_xalloc() or other function to specify
bbram, but that seems to have disappeared.
>Sorry for the questions, but info on the RCM3200 seems hard to come
>by, unless I'm just not looking in the right place.
No, the 3200 is not documented at all. It's memory map is different and how
the different compile modes effect things is only documented by reading the
bios and boardtypes.lib. The 3300 looks similar.
There is almost no docs on the bbram keyword. It looks like it allocates a
4k root area to page into the 256k RAM. But, docs are non-existent.
<Scott
>So, does anyone know of any restrictions regarding xalloc's (or any
>other function calls, for that matter) in GLOBAL_INIT's when "run in
>RAM" is selected on the RCM3200? It appears to not work. When I
>changed this xalloc call to be done within the scope of the program
>to init this pointer, all works fine with "run in RAM" compile
>selected.
You can not guarantee the order of GLOBAL_INIT's. Probably the xmem init is
set up in a later GLOABL_INIT. I avoid GLOBAL_INIT's at all costs. >2. Another question: I was looking at Scott's post #19616, and the
>#18759 thread regarding the RAM mappings when "code and bios in
>flash" and "code and bios in flash, run in RAM" is selected, and
>this seems to make sense. What I can't tell, however, is if the
>code size is less than 512kB (which means the fast RAM is not full),
>is the remainder of the fast RAM IC made available for RAM
>allocations, or is it treated as though it were "flash", and
>therefore xalloc's would start at physical address 0x80000 (where
>the 256kB bbRAM IC is located)? I'm asking because I expected this
>xalloc result to be in the range of 0x80000-0xBFFFF (which it is
>when "code and bios in flash" is chosen), but it's returning a value
>0x7xxxx (above my code but presumably within the 512kB fast RAM
>space).
Yes, it will use the fast RAM first, then the slow RAM. There was a
reference in 7.x to some upcoming bb_xalloc() or other function to specify
bbram, but that seems to have disappeared.
>Sorry for the questions, but info on the RCM3200 seems hard to come
>by, unless I'm just not looking in the right place.
No, the 3200 is not documented at all. It's memory map is different and how
the different compile modes effect things is only documented by reading the
bios and boardtypes.lib. The 3300 looks similar.
There is almost no docs on the bbram keyword. It looks like it allocates a
4k root area to page into the 256k RAM. But, docs are non-existent.
<Scott
