Internal Error: Cannot generate code around origin directive specifier

What does the following compiler error mean?

"Internal Error: Cannot generate code around origin directive
specifier. Please contact Z-World."

I have no "origin directive" in my code. And the error is on a line
of code in a file that hasn't changed in months.

Steve

FYI...I'm using DC v8.20P Start a New Thread

Some additional information regarding this issue, is that the
compiler error will go away if I turn off debug code. It will
also go away if I remove some amount of code from my program.
And it doesn't matter if I remove the new code I added or some
old code that's been running for years and is unchanged.

So it would appear that I've hit some sort of maximum code level.
My program is 222k compiled without debug, and about 240k with
debug enabled. I'm using a R3000 with 512k flash and 512k of ram.

Any ideas?

Steve Start a New Thread

What is the Rabbit 3000 board model? What compile mode (to flash, or to
RAM, or to flash to run in fast RAM) is being used? Does your Rabbit 3000
board have a single 512 KB flash, or 2*256 KB flashes? If it has 2*256 KB
flashes, have you edited RabbitBios.c to uncomment the "#define
USE_2NDFLASH_CODE" line? Note that doing this precludes the use of the
second flash for a file system. Start a New Thread

I'm using an RCM3000, which has 2 flash devices and 1 ram device.
I'm compiling to flash and running out of flash.

In my project window options, under the "Defines" tab I had put
USE_2NDFLASH_CODE. Do I need to do more?

Here is a second issue, loosely related to this issue. Since I can't
compile with a blanket debug enabled, I've enabled debug in a couple
of my libraries so that I can debug some new code, and set #nodebug
in all the rest of my libraries. I can now compile and run the
debugger, but I can't set a breakpoint on or in any of the new
procedures even though they are in the library that has an explicit
#debug at the very begining. All very strange behavior.

I'm using v8.20P.

Steve Start a New Thread

Adding USE_2NDFLASH_CODE in your Project Option's Defines tab should work OK.

Putting a #debug or #nodebug directive in any part of a library does not
necessarily affect the entire library, and may affect other parts of
application or library code. This is because Dynamic C views libraries as
groups of modules, and not as a whole. (Unless the entire library is one
module, of course.)

In any case, the local usage in a function definition of debug or nodebug
will override the global #debug or #nodebug directive. If you do not
specify debug or nodebug, then C functions default to debug and #asm
functions default to nodebug. You might try using a library specific debug
macro, such as is done with "#define _tcp_nodebug debug" in tcp.lib, for
example.

I am checking with another Engineer at Z-World regarding the internal error
that you have mentioned. Does shuffling the order of functions (not
function calls) in your main application code affect the internal error
report? (Particularly functions toward the end of your main application
code.) Also, do you #ximport or #zimport files? Is separate I&D space
enabled? Start a New Thread

In order to answer your question about whether moving code around
affects the error, I removed all the #nodebug statements from my
libraries and restored them back to their original condition as
follows. At the top of each library file is the following:

#ifdef _NODEBUG_
#nodebug
#else
#debug
#endif

In my main file I have "#define _NODEBUG_" that I either comment out
or not, depending on whether I want to run the debugger.

After I restored all my libraries back to the condition above, I can
now compile with debug enabled without errors. I don't know what
caused the problem to begin with or why it now went away.

To answer your other questions, though they may be academic at this
point, I do not #ximport or #zimport files and I do not use separate
I&D.

The other #debug / #nodebug issue is interesting. First, let me
correct my previous statement. I can set breakpoints within the two
new procedures I've added to the program. What I can't do is set a
breakpoint on the procedure call itself. The call is in my main
program file and the procedures are in a library file. If I do set a
breakpoint in the procedure, I do break there, which tells me that
the procedure call is an active line of code. I can even set a
breakpoint on the line of code before the procedure calls in question
and step into my procedure. I just can't set a breakpoint on the call
itself. And its only on the calls to these 2 new procedures I've
added.

I just downloaded version 8.51 of DC and will give that a try.
Perhaps it will behave better. But even if it does work better in
this area, the DHCP portion needs to work in order for me to use it.
DHCP does not work for me when using 8.30, which is why I've stayed
with V8.20.

Thanks for your help.
Steve Start a New Thread

Additionally, if you're trying to compile to RAM, this may be of some use
to you:

The default behavior, in RabbitBios.c, is to logically split a 512 KB RAM
in half, leaving the upper 256 KB as one large chunk that is available to
xalloc.

To make the entire 512 KB of RAM available to additional xmem code (at the
expense of the corresponding amount of xmem data for xalloc) in RAM compile
mode, in RabbitBios.c search for the line that reads "#define RAM_SIZE
0x40" and edit it to read "#define RAM_SIZE _RAM_SIZE_" instead. Start a New Thread